From 3a467eff5e435b5709d48f9d6cb48859925be5b8 Mon Sep 17 00:00:00 2001 From: root Date: Sat, 21 Mar 2009 11:49:00 +0100 Subject: checked in initial version --- doc/001291.html | 242 ++++++++ doc/CROSS-COMPILE-GUTS | 284 ++++++++++ doc/HOWTO_bbox_with_uclibc.txt | 302 ++++++++++ doc/LINKS | 56 ++ doc/buildMin.html | 87 +++ doc/crosstool-howto.html | 634 +++++++++++++++++++++ doc/embedded_lfs.odp | Bin 0 -> 164275 bytes doc/qemu_to_vmware_image.html | 1198 ++++++++++++++++++++++++++++++++++++++++ doc/tutorial.txt | 390 +++++++++++++ doc/uclibc-bootfloppy.txt | 667 ++++++++++++++++++++++ 10 files changed, 3860 insertions(+) create mode 100644 doc/001291.html create mode 100644 doc/CROSS-COMPILE-GUTS create mode 100644 doc/HOWTO_bbox_with_uclibc.txt create mode 100644 doc/LINKS create mode 100644 doc/buildMin.html create mode 100644 doc/crosstool-howto.html create mode 100644 doc/embedded_lfs.odp create mode 100644 doc/qemu_to_vmware_image.html create mode 100644 doc/tutorial.txt create mode 100644 doc/uclibc-bootfloppy.txt (limited to 'doc') diff --git a/doc/001291.html b/doc/001291.html new file mode 100644 index 0000000..5115daf --- /dev/null +++ b/doc/001291.html @@ -0,0 +1,242 @@ + + + + uclibc vs glibc + + + + + + + + + +

uclibc vs glibc

+ Robert Connolly + robert at linuxfromscratch.org +
+ Sun Nov 7 00:10:55 MST 2004 +

+
+ +
I think I have success, except that the host system is detected as -gnu 
+instead of -uclibc. But otherwise its working fine {:-] I attached my 
+instruction sheet. It appears as though we need to use --host/build/target on 
+every package, but I'm starting to get the feeling it doesn't really matter 
+excpet for packages that are patched for it. I'm interested to know what 
+happens in chapter 6.
+
+Gawk's testsuite passed. Coreutils did not... it fails strait away.
+
+make[3]: Entering directory 
+`/mnt/hlfs/sources/temp/coreutils-5.2.1/tests/basename'
+-: test fail-1: stderr mismatch, comparing fail-1.1 (actual) and fail-1.E 
+(expected)
+*** fail-1.1    Sun Nov  7 02:02:47 2004
+--- fail-1.E    Sun Nov  7 02:02:47 2004
+
+If I run Coreutils tests with make -k I get a lot of passes, but a lot of 
+failures too. Odd stuff, like no such file, and permission denied, and 
+mismatches too. Coreutils doesn't leave me any .out files to look at so I'll 
+shelf this for now and I'll try to get to chapter 6 (tommorrow).
+
+nini
+Robert
+-------------- next part --------------
+# LFS with uclibc
+# robert
+
+# This is so the cross linker is found for cross gcc's build, and again for uClibc.
+# It gets removed after native tools are set up.
+# This path must go on the end so the native tools in /tools/bin are used when
+# they get installed.
+
+export PATH="$PATH:/tools/cross/bin"
+
+- Uclibc unpack
+
+Just unpack it.
+
+- Linux-libc-headers 2.6
+
+cp -R include/asm-i386 ../uClibc/include/asm &&
+cp -R include/{linux,sound} ../uClibc/include
+
+- Uclibc headers
+
+make allyesconfig &&
+sed 's at RUNTIME_PREFIX.*@RUNTIME_PREFIX="/tools"@' -i .config &&
+echo > extra/scripts/fix_includes.sh
+
+# This is better than 'cp -R include /tools/include' because this doesn't install
+# libintl.h because it doesn't seem to work.
+# Ignore the error about missing lib/
+
+make headers
+make DEVEL_PREFIX=/tools/cross/i386-pc-linux-uclibc/ install_dev
+
+# Remove this broken link (lets not pretend it works).
+# Then remove the empty directory (lets not pretend something is inside).
+
+rm /tools/cross/i386-pc-linux-uclibc/lib/libthread_db.so &&
+rmdir /tools/cross/i386-pc-linux-uclibc/lib/
+
+- Binutils cross linker
+
+# The second patch might not be needed, but I don't think it hurts either.
+
+cat ../binutils-2.15.90.0.3-uclibc-100-conf.patch \
+	| sed -e 's@/lib/@/tools/lib/@g' | patch -Np1 &&
+patch -Np1 -i ../binutils-2.15.90.0.3-uclibc-210-cflags.patch
+
+mkdir ../binutils-build &&
+cd ../binutils-build 
+
+../binutils-2.15.90.0.3/configure --prefix=/tools/cross --disable-nls \
+        --target=i386-pc-linux-uclibc &&
+make configure-host &&
+make LDFLAGS="-all-static" &&
+make install &&
+make -C ld clean &&
+make -C ld LDFLAGS="-all-static" LIB_PATH=/tools/lib
+
+- Gcc cross compiler
+
+# Just unpack gcc-core
+
+# This is a replacement for the LFS specs patch, and adds uClibc specific stuff so
+# --target=uclibc works nicer.
+patch -Np1 -i ../gcc-3.4.3-uclibc_tools_conf-1.patch
+
+mkdir ../gcc-build &&
+cd ../gcc-build
+
+# The most important thing here is --disable-shared. Untill we have a native C library
+# Gcc can not build a libgcc.so (because it uses functions from libc.so).
+../gcc-3.4.3/configure --prefix=/tools/cross --target=i386-pc-linux-uclibc \
+    --libexecdir=/tools/cross/i386-pc-linux-uclibc/lib \
+    --with-local-prefix=/tools/cross \
+    --disable-nls --disable-shared --enable-languages=c
+
+# Not BOOT_LDFLAGS because we are not doing a bootstrap here.
+make LDFLAGS="-static"
+
+make install
+
+- uClibc build
+
+make CROSS=i386-pc-linux-uclibc-
+
+make RUNTIME_PREFIX=/tools/ install_runtime
+make DEVEL_PREFIX=/tools/ install_dev
+
+- Adjusting toolchain
+
+# In binutils-build
+make -C ld install
+
+# I dont know how to avoid this. Its only for use durring cross compiling.
+ln -s /tools/lib/crt* /tools/cross/i386-pc-linux-uclibc/lib
+
+# Theres no sed(1) command in this, the gcc-uclibc-conf patch took care of it.
+# Now test that the compiler works.
+echo 'main(){}' > dummy.c
+i386-pc-linux-uclibc-gcc dummy.c
+readelf -l a.out | grep ': /tools'
+
+- Gcc native
+
+patch -Np1 -i ../gcc-3.4.3-uclibc_tools_conf-1.patch 
+
+# This patch tells GCC how to build with uClibc locales for c++.
+patch -Np1 -i ../gcc-3.4.1-uclibc-200-locale.patch
+
+# This is so we don't run the fixincludes scripts.
+patch -Np1 -i ../gcc-3.4.3-no_fixincludes-1.patch
+
+mkdir ../gcc-build &&
+cd ../gcc-build
+
+# Uclibc and __cxa_atexit don't get along. --enable-clocale=uclibc, but don't define
+# that or else it won't work, it will be echo'd during configure though.
+
+# The first pass will be with the cross compiler, the bootstrap is with the native.
+CC="i386-pc-linux-uclibc-gcc" \
+../gcc-3.4.3/configure --prefix=/tools \
+    --host=i386-pc-linux-uclibc --build=i386-pc-linux-uclibc \
+    --target=i386-pc-linux-uclibc --enable-shared \
+    --libexecdir=/tools/lib --with-local-prefix=/tools \
+    --enable-threads=posix --disable-__cxa_atexit \
+    --enable-languages=c,c++ --disable-libstdcxx-pch
+
+make bootstrap
+
+make install &&
+ln -s gcc /tools/bin/cc
+
+- Binutils native
+
+cat ../binutils-2.15.90.0.3-uclibc-100-conf.patch \
+        | sed -e 's@/lib/@/tools/lib/@g' | patch -Np1 &&
+patch -Np1 -i ../binutils-2.15.90.0.3-uclibc-210-cflags.patch
+
+mkdir ../binutils-build &&
+cd ../binutils-build
+
+../binutils-2.15.90.0.3/configure --prefix=/tools \
+	--enable-shared --with-lib-path=/tools/lib \
+	--host=i386-pc-linux-uclibc --build=i386-pc-linux-uclibc \
+    --target=i386-pc-linux-uclibc &&
+make &&
+make install &&
+make -C ld clean &&
+make -C ld LIB_PATH=/usr/lib:/lib
+
+- Gawk
+
+./configure --prefix=/tools --host=i386-pc-linux-uclibc \
+  --build=i386-pc-linux-uclibc --target=i386-pc-linux-uclibc &&
+make &&
+make install
+
+- Coreutils
+
+./configure --prefix=/tools --host=i386-pc-linux-uclibc \
+  --build=i386-pc-linux-uclibc --target=i386-pc-linux-uclibc &&
+make &&
+make install
+
+
+ + +
+

+ +
+More information about the hlfs-dev +mailing list
+ diff --git a/doc/CROSS-COMPILE-GUTS b/doc/CROSS-COMPILE-GUTS new file mode 100644 index 0000000..8453a6e --- /dev/null +++ b/doc/CROSS-COMPILE-GUTS @@ -0,0 +1,284 @@ +----- +Intro +----- + +2006-06-08 Mike Frysinger + +brain dumpage of cross-compiling low level details + +target audience: +people who (for some stupid reason or another) really really want to create +their own cross compiler with binutils/(glibc|uclibc)/gcc all by themselves. + +what this isn't: +this document makes no attempt whatsoever to cover the myriad of build +failures you are likely to see along the way. if you need such help, see the +References section at the end of this file for some pointers. don't bug me :P + + +-------- +Overview +-------- + +There are generally two ways to build up your cross-compiler. The "accepted" +way, and the cheater's shortcut. + +The current "accepted" way is: + (1) binutils + (2) kernel headers + (3) libc headers + (4) gcc stage1 (c-only) + (5) libc + (6) gcc stage2 (c/c++/etc...) + +The cheater's shortcut is: + (1) binutils + (2) gcc stage1 (c-only) + (3) kernel headers + (4) libc + (5) gcc stage2 (c/c++/etc...) + +The reason people are keen on the shortcut is that the libc headers step tends +to take quite a while, especially on slower machines. It can also be kind of +a pain to setup kernel/libc headers without a usuable cross compiler. Note +though that if you seek help with cross-compilers, upstream projects will not +want to help you if you took the shortcut. + +Also note that the shortcut requires the gcc stage1 to be "crippled". Since +you're building without headers, you cannot enable the sysroot option nor can +you build up proper gcc libs. This is OK if the only thing you use the stage1 +is building the C library and a kernel, but beyond that you need a nice +sysroot based compiler. + +Below I will describe the "accepted" way as the steps are pretty much the +same. You just need some extra patches for gcc in order to take the shortcut. + + +------- +Targets +------- + + + + +------- +Sysroot +------- + +We will be cross-compiling using the sysroot method. But wtf is sysroot ? + +From the gcc docs: + Tells GCC to consider dir as the root of a tree that contains a (subset of) + the root filesystem of the target operating system. Target system headers, + libraries and run-time object files will be searched in there. + +The structure of the sysroot dir is the same as the root filesystem of the +machine you're targeting with the cross-compiler. In Gentoo/portage terms, +it's like using ROOT. Let's look at the typical setup. + +The top level dir is commonly rooted in /usr/$CTARGET +/usr/$CTARGET/ +|-- bin/ +|-- lib/ critical runtime libs (libc/ldso/etc...) +`-- usr/ + |-- include/ development headers + | |-- linux/ like the linux kernel + | `-- asm/ like the arch-specific + `-- lib/ non critical runtime libs / development libs + +As you can see, it's just like the directory setup / but in /usr/$CTARGET. +This setup is on purpose so you can easily migrate applications/libraries +out of /usr/$CTARGET and into / on your target board. + +Non-sysroot note: +The old style of cross-compilers was to use --prefix=/usr/$CTARGET. If you +are using versions of binutils/gcc that predate sysroot support, you may have +to do just this. + + +-------- +Binutils +-------- + +Grab the binutils-2.16.1.tar.bz2 tarball and unpack it. + +The --disable-werror configure option is to prevent binutils from aborting +the compile due to warnings. Great feature for developers, pita for users. + +To configure/build/install: + +$ ./configure \ + --target=$CTARGET \ + --prefix=/usr \ + --with-sysroot=/usr/$CTARGET \ + --disable-werror +$ make +$ make install DESTDIR=$PWD/install-root + +The reason we install into the localdir is so we can remove crap that doesn't +belong. For example, a normal install will give us /usr/lib/libiberty.a which +doesn't belong in our host /usr/lib. So clean out stuff first: + +$ rm -rf install-root/usr/{info,lib,man,share} + +And install what's left: + +# cp -a install-root/* / + + +-------------- +Kernel headers +-------------- + +Grab the linux-2.6.16.tar.bz2 tarball and unpack it. + +$ yes "" | make ARCH=$ARCH oldconfig prepare + +With 2.6.x, this will probably end in an error because you don't have a gcc +cross-compiler yet, but you can ignore that. Just copy over the headers: + +# mkdir -p /usr/$CTARGET/usr/include +# cp -a include/linux include/asm-generic /usr/$CTARGET/usr/include/ +# cp -a include/asm-$ARCH /usr/$CTARGET/usr/include/asm + + +------------ +libc headers +------------ + + -- glibc -- + +Grab the glibc-2.4.tar.bz2 tarball and unpack it. Glibc is picky, so you'll +have to compile in a dir separate from the source code. + +Again, you'll probably see errors because you don't have a gcc cross-compiler +yet, but just ignore them. + +$ mkdir build +$ cd build +$ ../configure \ + --host=$CTARGET \ + --prefix=/usr \ + --with-headers=/usr/$CTARGET/usr/include \ + --disable-sanity-checks +# make -k install-headers install_root=/usr/$CTARGET + +glibc sucks at life so you have to do a few things by hand: + +# mkdir -p /usr/$CTARGET/usr/include/gnu +# touch /usr/$CTARGET/usr/include/gnu/stubs.h +# cp bits/stdio_lim.h /usr/$CTARGET/usr/include/bits/ + + + -- uClibc -- + +Grab the uClibc-0.9.28.tar.bz2 tarball and unpack it. + + +---------- +GCC stage1 +---------- + +We first have to help gcc find the current libc headers. + +# ln -s usr/include /usr/$CTARGET/sys-include + +Grab the gcc-4.1.1.tar.bz2 tarball and unpack it. + +$ mkdir build +$ cd build +$ ../configure \ + --target=$CTARGET \ + --prefix=/usr \ + --with-sysroot=/usr/$CTARGET \ + --enable-languages=c \ + --disable-shared \ + --disable-checking \ + --disable-werror \ + --disable-libmudflap \ + --disable-libssp +$ make +$ make install DESTDIR=$PWD/install-root + +Same as binutils, gcc leaves some stuff behind we don't want. + +$ rm -rf install-root/usr/{info,include,lib/libiberty.a,man,share} + +Install what's left: + +# cp -a install-root/* / + + +---------- +libc +---------- + + -- glibc -- + +Nuke the old glibc build dir and recreate it. + +$ rm -rf build +$ mkdir build +$ cd build +$ ../configure \ + --host=$CTARGET \ + --prefix=/usr +$ make +# make install install_root=/usr/$CTARGET + + -- uClibc -- + + + +---------- +GCC stage2 +---------- + +$ ./configure \ + --target=$CTARGET \ + --prefix=/usr \ + --with-sysroot=/usr/$CTARGET \ + --enable-languages=c,c++ \ + --enable-shared \ + --disable-checking \ + --disable-werror +$ make +# make install + + +---- +Help +---- + +Where to seek help: +The crossgcc mailing list: http://sourceware.org/ml/crossgcc/ +Google: http://www.google.com/ + + +---------- +References +---------- + +Gentoo Homepage: http://embedded.gentoo.org/ + +crosstool: http://www.kegel.com/crosstool/ + +Binutils Homepage: http://sourceware.org/binutils/ +Binutils Download: http://ftp.gnu.org/gnu/binutils/ +Binutils Manual: http://sourceware.org/binutils/docs-2.16/ + +GCC Homepage: http://gcc.gnu.org/ +GCC Download: http://ftp.gnu.org/gnu/gcc/ +GCC Manual: http://gcc.gnu.org/onlinedocs/ +GCC Install Docs: http://gcc.gnu.org/install/ + +Glibc Homepage: http://www.gnu.org/software/libc/ +Glibc Download: http://ftp.gnu.org/gnu/glibc/ +Glibc Manual: http://www.gnu.org/software/libc/manual/ +Glibc Install Docs: http://www.gnu.org/software/libc/manual/html_node/Installation.html#Installation + +uClibc Homepage: http://www.uClibc.org/ +uClibc Download: http://www.uclibc.org/downloads/ + +Linux Kernel Homepage: http://www.kernel.org/ +Linux Kernel Download: http://www.kernel.org/pub/linux/kernel/ diff --git a/doc/HOWTO_bbox_with_uclibc.txt b/doc/HOWTO_bbox_with_uclibc.txt new file mode 100644 index 0000000..bcbbbb6 --- /dev/null +++ b/doc/HOWTO_bbox_with_uclibc.txt @@ -0,0 +1,302 @@ +How to build busybox statically against uclibc, minimizing its size. + +Very sketchy at the moment. Send questions to vda.linux@googlemail.com. + +First, build and install cross-compiling toolchain. Start with binutils. +When binutils are built and installed, you should have these files: + +$ ls -l /usr/bin/i486-linux-uclibc-* | grep binutils +lrwxrwxrwx 1 root root 72 Jul 21 18:17 /usr/bin/i486-linux-uclibc-addr2line -> /usr/app/binutils-2.17-i486-linux-uclibc/bin/i486-linux-uclibc-addr2line +lrwxrwxrwx 1 root root 65 Jul 21 18:17 /usr/bin/i486-linux-uclibc-ar -> /usr/app/binutils-2.17-i486-linux-uclibc/bin/i486-linux-uclibc-ar +lrwxrwxrwx 1 root root 65 Jul 21 18:17 /usr/bin/i486-linux-uclibc-as -> /usr/app/binutils-2.17-i486-linux-uclibc/bin/i486-linux-uclibc-as +lrwxrwxrwx 1 root root 70 Jul 21 18:17 /usr/bin/i486-linux-uclibc-c++filt -> /usr/app/binutils-2.17-i486-linux-uclibc/bin/i486-linux-uclibc-c++filt +lrwxrwxrwx 1 root root 65 Jul 21 18:17 /usr/bin/i486-linux-uclibc-ld -> /usr/app/binutils-2.17-i486-linux-uclibc/bin/i486-linux-uclibc-ld +lrwxrwxrwx 1 root root 65 Jul 21 18:17 /usr/bin/i486-linux-uclibc-nm -> /usr/app/binutils-2.17-i486-linux-uclibc/bin/i486-linux-uclibc-nm +lrwxrwxrwx 1 root root 70 Jul 21 18:17 /usr/bin/i486-linux-uclibc-objcopy -> /usr/app/binutils-2.17-i486-linux-uclibc/bin/i486-linux-uclibc-objcopy +lrwxrwxrwx 1 root root 70 Jul 21 18:17 /usr/bin/i486-linux-uclibc-objdump -> /usr/app/binutils-2.17-i486-linux-uclibc/bin/i486-linux-uclibc-objdump +lrwxrwxrwx 1 root root 69 Jul 21 18:17 /usr/bin/i486-linux-uclibc-ranlib -> /usr/app/binutils-2.17-i486-linux-uclibc/bin/i486-linux-uclibc-ranlib +lrwxrwxrwx 1 root root 70 Jul 21 18:17 /usr/bin/i486-linux-uclibc-readelf -> /usr/app/binutils-2.17-i486-linux-uclibc/bin/i486-linux-uclibc-readelf +lrwxrwxrwx 1 root root 67 Jul 21 18:17 /usr/bin/i486-linux-uclibc-size -> /usr/app/binutils-2.17-i486-linux-uclibc/bin/i486-linux-uclibc-size +lrwxrwxrwx 1 root root 70 Jul 21 18:17 /usr/bin/i486-linux-uclibc-strings -> /usr/app/binutils-2.17-i486-linux-uclibc/bin/i486-linux-uclibc-strings +lrwxrwxrwx 1 root root 68 Jul 21 18:17 /usr/bin/i486-linux-uclibc-strip -> /usr/app/binutils-2.17-i486-linux-uclibc/bin/i486-linux-uclibc-strip + +After that, build cross-gcc. You should now have this: + +$ ls -l /usr/bin/i486-linux-uclibc-* | grep -v binutils +lrwxrwxrwx 1 root root 62 Aug 21 13:38 /usr/bin/i486-linux-uclibc-c++ -> /usr/app/gcc-4.2.1-i486-linux-uclibc/bin/i486-linux-uclibc-c++ +lrwxrwxrwx 1 root root 62 Aug 21 13:38 /usr/bin/i486-linux-uclibc-cpp -> /usr/app/gcc-4.2.1-i486-linux-uclibc/bin/i486-linux-uclibc-cpp +lrwxrwxrwx 1 root root 62 Aug 21 13:38 /usr/bin/i486-linux-uclibc-g++ -> /usr/app/gcc-4.2.1-i486-linux-uclibc/bin/i486-linux-uclibc-g++ +lrwxrwxrwx 1 root root 62 Aug 21 13:38 /usr/bin/i486-linux-uclibc-gcc -> /usr/app/gcc-4.2.1-i486-linux-uclibc/bin/i486-linux-uclibc-gcc +lrwxrwxrwx 1 root root 68 Aug 21 12:43 /usr/bin/i486-linux-uclibc-gcc-4.1.1 -> /usr/app/gcc-4.1.1-i486-linux-uclibc/bin/i486-linux-uclibc-gcc-4.1.1 +lrwxrwxrwx 1 root root 68 Aug 21 13:38 /usr/bin/i486-linux-uclibc-gcc-4.2.1 -> /usr/app/gcc-4.2.1-i486-linux-uclibc/bin/i486-linux-uclibc-gcc-4.2.1 +lrwxrwxrwx 1 root root 65 Aug 21 13:38 /usr/bin/i486-linux-uclibc-gccbug -> /usr/app/gcc-4.2.1-i486-linux-uclibc/bin/i486-linux-uclibc-gccbug +lrwxrwxrwx 1 root root 63 Aug 21 13:38 /usr/bin/i486-linux-uclibc-gcov -> /usr/app/gcc-4.2.1-i486-linux-uclibc/bin/i486-linux-uclibc-gcov + +Depending on your packaging choice, you may end up with actual files in /usr/bin, +not symlinks. In fact, having symlinks is not typical, but I find it much +more convenient. + +Now you need to build uclibc. +Full uclibc .config can be found at the end of this file. +Key points: + +Uncheck shared library support: +[ ] Generate only Position Independent Code (PIC) +[ ] Enable support for shared libraries + +Since busybox uses --gc-sections, it's advantageous to pass +"-ffunction-sections -fdata-sections" options to gcc. This will make +your busybox binary ~6k smaller. I set the following option +in .config for that: + +UCLIBC_EXTRA_CFLAGS="-ffunction-sections -fdata-sections -falign-functions=1 -falign-labels=1 -falign-loops=1 -falign-jumps=1 -fomit-frame-pointer" + +Build and install you uclibc. + +Now you can build busybox against it by using + +export ARCH=i386 +make CROSS_COMPILE=i486-linux-uclibc- ... + +After you built it, find busybox_ld.out file in the top build directory, +rename it to busybox_ldscript, remove everything except linker script, +and edit it as follows: + +--- busybox_ld.out 2007-09-16 20:19:51.000000000 +0100 ++++ busybox_ldscript 2007-08-25 18:10:15.000000000 +0100 +@@ -65,7 +65,7 @@ + PROVIDE (__etext = .); + PROVIDE (_etext = .); + PROVIDE (etext = .); +- .rodata : { *(.rodata .rodata.* .gnu.linkonce.r.*) } ++ .rodata : { *(.rodata SORT_BY_ALIGNMENT(.rodata.*) .gnu.linkonce.r.*) } + .rodata1 : { *(.rodata1) } + .eh_frame_hdr : { *(.eh_frame_hdr) } + .eh_frame : ONLY_IF_RO { KEEP (*(.eh_frame)) } +@@ -134,7 +134,7 @@ + .got.plt : { *(.got.plt) } + .data : + { +- *(.data .data.* .gnu.linkonce.d.*) ++ *(.data SORT_BY_ALIGNMENT(.data.*) .gnu.linkonce.d.*) + KEEP (*(.gnu.linkonce.d.*personality*)) + SORT(CONSTRUCTORS) + } +@@ -144,7 +144,7 @@ + .bss : + { + *(.dynbss) +- *(.bss .bss.* .gnu.linkonce.b.*) ++ *(.bss SORT_BY_ALIGNMENT(.bss.*) .gnu.linkonce.b.*) + *(COMMON) + /* Align here to ensure that the .bss section occupies space up to + _end. Align after .bss to ensure correct alignment even if the + +Now delete busybox and busybox_unstripped binaries, and rerun make. +It will do final link again, with smaller result. Example: + +$ size busybox busybox.optimized + text data bss dec hex filename + 772898 1084 10844 784826 bf9ba busybox + 772680 1051 10724 784455 bf847 busybox.optimized + +Nearly 400 bytes saved on padding. + +Sample uclibc .config follows +============================= +# +# Automatically generated make config: don't edit +# Fri Aug 3 12:16:10 2007 +# +# TARGET_alpha is not set +# TARGET_arm is not set +# TARGET_bfin is not set +# TARGET_cris is not set +# TARGET_e1 is not set +# TARGET_frv is not set +# TARGET_h8300 is not set +# TARGET_hppa is not set +TARGET_i386=y +# TARGET_i960 is not set +# TARGET_ia64 is not set +# TARGET_m68k is not set +# TARGET_microblaze is not set +# TARGET_mips is not set +# TARGET_nios is not set +# TARGET_nios2 is not set +# TARGET_powerpc is not set +# TARGET_sh is not set +# TARGET_sh64 is not set +# TARGET_sparc is not set +# TARGET_v850 is not set +# TARGET_vax is not set +# TARGET_x86_64 is not set + +# +# Target Architecture Features and Options +# +TARGET_ARCH="i386" +FORCE_OPTIONS_FOR_ARCH=y +# CONFIG_GENERIC_386 is not set +# CONFIG_386 is not set +CONFIG_486=y +# CONFIG_586 is not set +# CONFIG_586MMX is not set +# CONFIG_686 is not set +# CONFIG_PENTIUMII is not set +# CONFIG_PENTIUMIII is not set +# CONFIG_PENTIUM4 is not set +# CONFIG_K6 is not set +# CONFIG_K7 is not set +# CONFIG_ELAN is not set +# CONFIG_CRUSOE is not set +# CONFIG_WINCHIPC6 is not set +# CONFIG_WINCHIP2 is not set +# CONFIG_CYRIXIII is not set +# CONFIG_NEHEMIAH is not set +TARGET_SUBARCH="" + +# +# Using ELF file format +# +ARCH_LITTLE_ENDIAN=y + +# +# Using Little Endian +# +ARCH_HAS_MMU=y +ARCH_USE_MMU=y +UCLIBC_HAS_FLOATS=y +UCLIBC_HAS_FPU=y +DO_C99_MATH=y +KERNEL_HEADERS="../linux-2.6.18.1/include" +HAVE_DOT_CONFIG=y + +# +# General Library Settings +# +# HAVE_NO_PIC is not set +# DOPIC is not set +# HAVE_NO_SHARED is not set +# ARCH_HAS_NO_LDSO is not set +# HAVE_SHARED is not set +UCLIBC_CTOR_DTOR=y +# HAS_NO_THREADS is not set +# UCLIBC_HAS_THREADS is not set +UCLIBC_HAS_LFS=y +# MALLOC is not set +# MALLOC_SIMPLE is not set +MALLOC_STANDARD=y +# MALLOC_GLIBC_COMPAT is not set +UCLIBC_DYNAMIC_ATEXIT=y +# COMPAT_ATEXIT is not set +# UCLIBC_SUSV3_LEGACY is not set +# UCLIBC_SUSV3_LEGACY_MACROS is not set +UCLIBC_HAS_SHADOW=y +# UCLIBC_HAS_PROGRAM_INVOCATION_NAME is not set +UCLIBC_HAS___PROGNAME=y +UNIX98PTY_ONLY=y +ASSUME_DEVPTS=y +UCLIBC_HAS_TM_EXTENSIONS=y +UCLIBC_HAS_TZ_CACHING=y +UCLIBC_HAS_TZ_FILE=y +UCLIBC_HAS_TZ_FILE_READ_MANY=y +UCLIBC_TZ_FILE_PATH="/etc/TZ" + +# +# Advanced Library Settings +# +UCLIBC_PWD_BUFFER_SIZE=256 +UCLIBC_GRP_BUFFER_SIZE=256 + +# +# Networking Support +# +UCLIBC_HAS_IPV6=y +UCLIBC_HAS_RPC=y +UCLIBC_HAS_FULL_RPC=y +UCLIBC_HAS_REENTRANT_RPC=y +# UCLIBC_USE_NETLINK is not set +# UCLIBC_HAS_BSD_RES_CLOSE is not set + +# +# String and Stdio Support +# +UCLIBC_HAS_STRING_GENERIC_OPT=y +UCLIBC_HAS_STRING_ARCH_OPT=y +UCLIBC_HAS_CTYPE_TABLES=y +UCLIBC_HAS_CTYPE_SIGNED=y +UCLIBC_HAS_CTYPE_UNSAFE=y +# UCLIBC_HAS_CTYPE_CHECKED is not set +# UCLIBC_HAS_CTYPE_ENFORCED is not set +# UCLIBC_HAS_WCHAR is not set +# UCLIBC_HAS_LOCALE is not set +# UCLIBC_HAS_HEXADECIMAL_FLOATS is not set +# UCLIBC_HAS_GLIBC_CUSTOM_PRINTF is not set +# USE_OLD_VFPRINTF is not set +UCLIBC_PRINTF_SCANF_POSITIONAL_ARGS=9 +# UCLIBC_HAS_SCANF_GLIBC_A_FLAG is not set +# UCLIBC_HAS_STDIO_BUFSIZ_NONE is not set +# UCLIBC_HAS_STDIO_BUFSIZ_256 is not set +# UCLIBC_HAS_STDIO_BUFSIZ_512 is not set +UCLIBC_HAS_STDIO_BUFSIZ_1024=y +# UCLIBC_HAS_STDIO_BUFSIZ_2048 is not set +# UCLIBC_HAS_STDIO_BUFSIZ_4096 is not set +# UCLIBC_HAS_STDIO_BUFSIZ_8192 is not set +UCLIBC_HAS_STDIO_BUILTIN_BUFFER_NONE=y +# UCLIBC_HAS_STDIO_BUILTIN_BUFFER_4 is not set +# UCLIBC_HAS_STDIO_BUILTIN_BUFFER_8 is not set +# UCLIBC_HAS_STDIO_SHUTDOWN_ON_ABORT is not set +UCLIBC_HAS_STDIO_GETC_MACRO=y +UCLIBC_HAS_STDIO_PUTC_MACRO=y +UCLIBC_HAS_STDIO_AUTO_RW_TRANSITION=y +# UCLIBC_HAS_FOPEN_LARGEFILE_MODE is not set +# UCLIBC_HAS_FOPEN_EXCLUSIVE_MODE is not set +# UCLIBC_HAS_GLIBC_CUSTOM_STREAMS is not set +UCLIBC_HAS_PRINTF_M_SPEC=y +UCLIBC_HAS_ERRNO_MESSAGES=y +# UCLIBC_HAS_SYS_ERRLIST is not set +UCLIBC_HAS_SIGNUM_MESSAGES=y +# UCLIBC_HAS_SYS_SIGLIST is not set +UCLIBC_HAS_GNU_GETOPT=y +UCLIBC_HAS_GNU_GETSUBOPT=y + +# +# Big and Tall +# +UCLIBC_HAS_REGEX=y +UCLIBC_HAS_REGEX_OLD=y +UCLIBC_HAS_FNMATCH=y +UCLIBC_HAS_FNMATCH_OLD=y +UCLIBC_HAS_WORDEXP=y +UCLIBC_HAS_FTW=y +UCLIBC_HAS_GLOB=y +# UCLIBC_HAS_GNU_GLOB is not set + +# +# Library Installation Options +# +RUNTIME_PREFIX="/usr/app/uclibc-NEW/$(TARGET_ARCH)/" +DEVEL_PREFIX="/usr/app/uclibc-NEW/$(TARGET_ARCH)/usr/" + +# +# Security options +# +# UCLIBC_HAS_ARC4RANDOM is not set +# HAVE_NO_SSP is not set +# UCLIBC_HAS_SSP is not set +UCLIBC_BUILD_NOEXECSTACK=y + +# +# uClibc development/debugging options +# +CROSS_COMPILER_PREFIX="" +UCLIBC_EXTRA_CFLAGS="-ffunction-sections -fdata-sections -falign-functions=1 -falign-labels=1 -falign-loops=1 -falign-jumps=1 -fomit-frame-pointer" +# DODEBUG is not set +DOSTRIP=y +# DOASSERTS is not set +# UCLIBC_MALLOC_DEBUGGING is not set +WARNINGS="-Wall" +# EXTRA_WARNINGS is not set +# DOMULTI is not set +# UCLIBC_MJN3_ONLY is not set diff --git a/doc/LINKS b/doc/LINKS new file mode 100644 index 0000000..1db78c1 --- /dev/null +++ b/doc/LINKS @@ -0,0 +1,56 @@ +Why this all? +------------ + +Imagine an appliance you can send by email to demonstrate your software. +Something like Centos 5.1 which gets 720MB in its minimal installation is +just comletely unusable.. + +Minix 3 would be my preferred choice though but it has no thread support (yet). + +disk image formats of different emulators +----------------------------------------- + +Transform QEMU image to VirtualBox image: +http://liquidat.wordpress.com/2007/11/23/howto-transform-a-qemu-image-to-a-virtualbox-image/ + +Transform QEMU image to VMWare image: +http://cri.ch/linux/docs/sk0020.html + +Transform VMWare image into a MS Virtual Disk image (VHD): +http://vmtoolkit.com/files/folders/converters/entry8.aspx + +VMWare on Windows logon problem: +http://communities.vmware.com/thread/88396;jsessionid=976F209BADCAF3F9AA1DA6C2910664DF?tstart=0&start=15 +(but most likely you need Administrator permission to access the VMWare auth +service which is a nono for user accounts!) + +cross compilation +----------------- + +howto: http://www.landley.net/ols/ols2007/tutorial.txt +crosstools: http://kegel.com/crosstool/crosstool-0.43/doc/crosstool-howto.html + +A little bit old, but quite interesting: +http://dev.gentoo.org/~vapier/CROSS-COMPILE-GUTS + +Minimal Linux from Boot to Bash: +http://axiom.anu.edu.au/~okeefe/p2b/buildMin/buildMin.html + +http://dev.gentoo.org/~vapier/CROSS-COMPILE-GUTS + +http://busybox.net/~vda/HOWTO_bbox_with_uclibc.txt +http://linuxfromscratch.org/pipermail/hlfs-dev/2004-November/001291.html +http://dev.gentoo.org/~vapier/CROSS-COMPILE-GUTS + +How to create a qemu image in combination with losetup and sfdisk +----------------------------------------------------------------- + +http://www.mail-archive.com/qemu-devel@nongnu.org/msg01205.html + +other small Linux projects +-------------------------- + +http://www.creo.hu/~csaba/lowlife/uclibc-bootfloppy.txt +http://cross-lfs.org +ttylinux +dsl damn small linux diff --git a/doc/buildMin.html b/doc/buildMin.html new file mode 100644 index 0000000..8183a3a --- /dev/null +++ b/doc/buildMin.html @@ -0,0 +1,87 @@ + + + + + How To Build a Minimal Linux System from Source Code + + + + + +Next +Previous +Contents +
+

How To Build a Minimal Linux System from Source Code

+ +

Greg O'Keefe, gcokeefe@postoffice.utas.edu.au

v0.8, September 2000 +

+These are instructions for building a minimal linux system from source code. +It used to be part of +From PowerUp to Bash Prompt +but I've separated it to keep both documents short and focussed. +The system we build here is very minimal, and not ready for +real work. If you want to build a practical system from scratch, see +Gerard Beekmans' +Linux From Scratch HOWTO instead. +
+

+

1. What You Will Need

+ +

+

2. The Filesystem

+ +

+

3. MAKEDEV

+ +

+

4. Kernel

+ +

+

5. Lilo

+ +

+

6. Glibc

+ +

+

7. SysVinit

+ +

+

8. Ncurses

+ +

+

9. Bash

+ +

+

10. Util-linux (getty and login)

+ +

+

11. Sh-utils

+ +

+

12. Towards Useability

+ +

+

13. More Information

+ + +

+

14. Administrivia

+ + +
+Next +Previous +Contents + + diff --git a/doc/crosstool-howto.html b/doc/crosstool-howto.html new file mode 100644 index 0000000..db44375 --- /dev/null +++ b/doc/crosstool-howto.html @@ -0,0 +1,634 @@ + + +crosstool-howto + + +

crosstool-howto

+Crosstool is a set of scripts to build and test several versions of gcc and glibc for +most architectures supported by glibc. +It will even download and patch the original tarballs for you. +The resulting script and associated patches, and the latest version of this doc, +are available at kegel.com/crosstool. +

+Crosstool was originally developed for embedded system developers, but is also useful for mainstream developers who +simply want their compiles to go fast or who need to build programs that +run on older versions of Linux (e.g. Red Hat 6.2), but don't want to develop +on those ancient systems. +

+It includes minimal patches for gcc and glibc needed to build a few combinations of +(alpha, arm, i686, ia64, mips, powerpc, powerpc64, sh4, sparc, sparc64, s390, x86_64) x +(gcc-2.95.3 ... gcc-4.0.0) x +(glibc-2.1.3 ... glibc-2.3.5). +

+It also supports building toolchains that target Cygwin; see demo-cygwin.sh. +

+Crosstool is a portable shell script. You can use it to build linux-targeted compilers that run +on Linux, Mac OS X, Solaris, and Cygwin. It includes support for creating hetrogenous build +clusters; it lets you use virtually every computer in the building, regardless of operating +system or CPU type, to speed up your Linux compiles. + +

Contents

+ + +

Quick Start

+Download and unpack. For instance: +
+wget http://kegel.com/crosstool/crosstool-0.42.tar.gz
+tar -xzvf crosstool-0.42.tar.gz
+cd crosstool-0.42
+
+Then look at the demo scripts; there's one for each supported CPU type. +For instance, demo-i686.sh is an example of how to build a toolchain that targets +the i686 processor. It sets three important variables: +
+TARBALLS_DIR=$HOME/downloads        # where it will save source tarballs
+RESULT_TOP=/opt/crosstool           # where it will install the tools
+GCC_LANGUAGES="c,c++,java,f77"      # which languages it will make compilers for
+
+It then builds gcc-3.4.0 and glibc-2.3.2 for i686 with the line +
+ eval `cat i686.dat gcc-3.4.0-glibc-2.3.2.dat`  sh all.sh --notest 
+
+Edit the script if you want to change any of these settings or versions. +Then (as root) create the directory /opt/crosstool and make it writable by you, and +finally (as yourself) run the demo script, e.g. +
+sudo mkdir /opt/crosstool
+sudo chown $USER /opt/crosstool
+sh demo-i686.sh
+
+When it finishes, you can run the new compiler as /opt/crosstool/gcc-3.4.0-glibc-2.3.2/i686-unknown-linux-gnu/bin/i686-unknown-linux-gnu-gcc. +(You might want to put /opt/crosstool/gcc-3.4.0-glibc-2.3.2/i686-unknown-linux-gnu/bin on your PATH; then you +can run the compiler as i686-unknown-linux-gnu-gcc.) + +

Static Builds

+If for some reason you want the resulting toolchain binaries to +be statically linked, set the following environment variables before +running crosstool.sh (or all.sh): +
+BINUTILS_EXTRA_CONFIG="LDFLAGS=-all-static"
+GCC_EXTRA_CONFIG="LDFLAGS=-static"
+
+ +

Building RPMs

+Building RPMs of the compiler used to be done by the same shell script, all.sh, with the --buildrpm option, +but that was not enough to satisfy real Linux distributions, which require true .src.rpm's. +So now the procedure to build an RPM is to first build the .src.rpm, then build the .rpm from +that, using rpmbuild in the traditional way. +

+A script demonstrating how to build .src.rpm's is buildsrpms.sh. +A script demonstrating how to build both .src.rpm's and .rpm's is buildrpms.sh. +Both of these are only examples; I use them myself to build a specific set of toolchains. +

+Each .src.rpm generated by buildsrpms.sh builds toolchains +for all supported CPUs, where 'supported' means 'the CPU is listed in the buildlogs directory as +having successfully built a working toolchain'. +This greatly cuts down on the number of .src.rpm's needed. +To build for just e.g. i686, run rpmbuild with options "--without all --with i686". + +

Faster builds with distcc

+You can use distcc to distribute compilation across multiple computers for faster compiles. +The distcc that comes with your version of Linux will work fine for most cases. +However, it may be more convenient to instead use the script 'mkdistcc.sh' +included with crosstool to install a crosstool-specific distcc +(partly because that's what the mkdistcclinks.sh script assumes, +and partly because it includes a patch that improves support for large hetrogenous clusters; see below). +

+To install distcc/distccd from source, run +

+RESULT_TOP=/opt/crosstool \
+TARBALLS_DIR=$HOME/downloads \
+sh mkdistcc.sh
+cd /opt/crosstool
+sh common/bin/mkdistcclinks.sh
+
+To set up distccd as a service, run +
+sudo sh /opt/crosstool/common/bin/install-distccd.sh
+
+

+Regardless of how you installed crosstool-distcc, you then need to +edit /opt/crosstool/common/etc/hosts and append the hostnames of all the computers running your distccd. +

+You can then run the distributed compiler as /opt/crosstool/gcc-3.3.3-glibc-2.3.2/i686-unknown-linux-gnu/distributed/bin/i686-unknown-linux-gnu-gcc. +(You might want to put /opt/crosstool/gcc-3.3.3-glibc-2.3.2/i686-unknown-linux-gnu/distributed/bin on your PATH; then you +can run the distributed compiler as i686-unknown-linux-gnu-gcc.) +

+To get any speed benefit, you'll need +to run several compiles in parallel. See e.g. make's +-j option. Also note that only simple compiling with the -c option, +not linking, is sped up, and that only C and C++ +compiles are distributed (fortran and java compiles are not distributed, +sorry). +

+Getting the best performance out of distcc is a fine art. +See e.g. Benjamin Meyer's page +"Distcc optimizations and how to compile kdelibs from scratch in six minutes". +

+You can monitor your distcc jobs by running +

+/opt/crosstool/common/bin/distccmon-test 5
+
+This will display a description of your active remote jobs once every five seconds. + +

Hetrogenous distcc clusters

+Here's a scenario sometimes useful at large universities or companies, where one often has a central file server which all clients access. +Crosstool is built for multiple versions of gcc and glibc, once for kind of workstation in the cluster, +and installed in e.g. /shared/crosstool/`config.guess`. +Compilers are invoked via absolute paths so toolchains with different versions of glibc can be distinguished. +The absolute path is built using config.guess so, regardless of which +kind of workstation the developer is on, he or she can invoke a compiler that can run on their workstation. +

+For example, when building a C program for modern x86 linux, developers set +

+CC=/shared/crosstool/`config.guess`/gcc-3.3.3-glibc-2.3.2/i686-unknown-linux-gnu/distributed/bin/i686-unknown-linux-gnu-gcc
+
+And when building a C program for old Red Hat Linux 6.2 x86, developers might set +
+CC=/shared/crosstool/`config.guess`/gcc-3.3.3-glibc-2.1.3/i686-unknown-linux-gnu/distributed/bin/i686-unknown-linux-gnu-gcc
+
+

+A tricky part of this scenario is that the distcc server needs to be able to handle absolute paths +for *other* architectures, possibly installed at a different location. +The patch patches/distcc-2.14/distcc-stringmap.patch, applied by mkdistcc.sh, +adds a feature to the distccd server to read a $prefix/etc/distcc/apps file containing absolute paths +to all known compilers, and to ignore all but the last N path components when locating the compiler to satisfy received compile requests. +The distccd startup scripts created by crosstool's install-distccd.sh turn on that feature. +

+gcc-3.4.0's precompiled headers and profile-driven optimization features +require lockstep synchronization, so they probably work only if the client and +the server are the same CPU type and operating system. (And using pch with distcc may require +apple's -fpch-preprocess patch; see http://gcc.gnu.org/ml/gcc/2003-03/msg00369.html) + +

Canadian Cross Builds

+Those long, strange names of the form "i686-unknown-linux-gnu" are called +GNU +configuration names. The GNU build and test scripts use these +extensively. When you run the demo-$CPU.sh script, it sources +the $CPU.dat file, which sets a variable TARGET containing the GNU configuration +name for the target CPU. For instance, i686.dat contains the line +
+TARGET=i686-unknown-linux-gnu
+
+In the general case, there can be three machine types: the build machine which builds the compilers, +the host machine where the compilers will run, and the target machine +for which the compilers will generate code. +

+Building compilers that will run on some other linux system +is called a Canadian Cross. It's useful if, say, you're putting together +a hetrogenous build cluster consisting of 32 bit and 64 bit workstations, +and you want to run natively compiled compilers on each. +

+To do a Canadian Cross build with crosstool, you have to run it three times: +

    +
  1. once to build a toolchain that runs on the build system and generates code for the host system +
  2. once to build a toolchain that runs on the build system and generates code for the target system +
  3. once to build a toolchain that runs on the host system and generates code for the target system +
+The last two runs are identical except that on the last run, you have to set a few environment variables: +
    +
  • GCC_HOST should be the GNU configuration name (e.g. powerpc-750-linux-gnu) of the host machine +
  • PATH must be set to include the bin directory of the host and target compilers that can run on the build machine +
  • CC, AR, and RANLIB have to be set to a compiler that generates code that runs on the host, +and versions of ar and ranlib that +can handle archives of code for the host. +
+demo-canadian.sh (when I finish it) will demonstrate how to get this working. +

+If you want the use resulting toolchain as a native toolchain, i.e. +if you want it to search /lib and /usr/lib, you'll probably need to edit +its specs file to set the cross_compiler parameter to 0; +see this thread in the crossgcc mailing list. + +

Scripts

+
    +
  • crosstool.sh: Compiles gcc and glibc. This is the most important file, and it can be used by itself, +without any other files from the tarball, if you are so inclined. +
  • getandpatch.sh: Download, unpack, and patch the binutils, linux, gcc, and glibc source tarballs. +
  • crosstest.sh: Run the gcc and glibc regression tests remotely. +
  • ptx.sh: Build userland apps (e.g. /bin/sh) using ptxdist. +
  • testhello.sh: Verifies trivial programs can be built with the new compiler +
  • all.sh: Invoke all the above scripts. Supposedly more convenient that running them individually. (See below.) +
  • mkdistcc.sh: A script to download, build, and patch distcc. +
  • mkdistcclinks.sh: A script to create masquerade directories for each installed compiler to make using distcc easier. +
  • demo-CPU.sh: One demo script for each CPU type that sets environment variables for that CPU, then runs all.sh and mkdistcc.sh. +
  • demo.sh: Big demo script that runs all the little demo-CPU.sh scripts. +
  • clean.sh: remove junk files; used by maintainer before creating tarballs +
  • mkjail.sh: create the files needed for a chroot jail (useful when doing regression testing of glibc) +
  • testjail.sh: test a remote chroot jail +
+ +

Data Files

+
    +
  • CPU.dat: One file for each CPU type; sets GNU target name +
  • gcc-VERSION-glibc-VERSION.dat: One file for each supported combination of gcc and glibc; sets binutils, gcc, and glibc versions and options +
  • patches/PROGRAM/*.patch: the patches I needed for each version of each program. +The patches for each tool are stored in a subdirectory of patches/ +named after the tool (e.g. patches/gcc-3.3). +Each patch starts with comments about what it's for, and has links to any associated discussion. +This is a small but hopefully high quality and maintainable patch repository; newer versions of ptxdist use a mirror of this repository. +
  • summaries/*: example outputs from old crosstest.sh runs +
+ +

Notes

+If you want to build gcc-3.3 or later, you'll need a recent gcc (3.2 or later) +on your workstation to build it with. +

+The scripts are fairly generic. +You may need to tweak the parameters of the script to match your exact CPU type, +or add a few patches needed to the patches/* directories, and run the build script again, +if your tests indicate that programs built with the new compiler have problems. +

+In particular, if your CPU lacks an FPU, you might need to tell glibc that by setting +before running all.sh. For example, see powerpc-405.dat, which sets +

+GLIBC_EXTRA_CONFIG="--without-fp"
+
+

+Once you trust the toolchain can build and run simple statically linked 'hello, world' programs +(see e.g. testhello.sh), test it with real applications. +

+If you use these scripts to build a toolchain, please send a note to the +crossgcc mailing list +indicating which platform you used it on, and +how well it worked for you. Please be sure to mention which release of the crosstool +scripts you used. +

+If you add support for a new CPU type, please send your changes to the crossgcc mailing +list so they can be incorporated in a future release. + +

Testing

+If you're targeting i686-linux, and are using a released version of gcc +and glibc, you probably don't need to worry about testing the toolchain. +

+But if you're using a new or uncommon CPU type, or an unreleased version +of gcc or glibc, and want some assurance that you have built a working +compiler and C library, you should run the gcc and glibc test suites. +See crosstest-howto.html. + +

all.sh

+all.sh invokes the four scripts that download, build, and test the toolchain. +It takes four options: +
    +
  • --nounpack, which means 'don't run getandbuild.sh'. This is useful for quick reruns or when just testing. +
  • --nobuild, which means 'don't run crosstool.sh'. This is useful for when you just want to run regression tests. +
  • --builduserland, which means 'run ptx.sh'. This is useful for when you need to build busybox for some reason, +e.g. if you want to run the regression tests, but the target's normal shell can't run against the new shared C libraries. +
  • --notest, which means 'don't run crosstest.sh'. This is useful for when you don't have a target to test on, +or don't want to spend the time to test. See crosstest-howto.html for information about running the test suite. +
+ +

Build Platform Notes

+ +

Linux

+Crosstool was developed on Linux, so most of the rough edges have been polished off. +However, if running crosstool.sh on Linux fails with an error like +
+"soinit.c:25: internal compiler error: in named_section_flags, at varasm.c:..."
+
+then you may be running into gcc bug 9552. +One workaround is to delete the file gcc-pr-9552-workaround.patch +from crosstool/patches/glibc-2.3.2, and rerun. Another is to switch +to a different version of binutils (2.14 seems to be the dividing line). + +

NetBSD

+You'll need to install GNU Diffutils or GNU Patch, since BSD's patch utility +doesn't accept the --fuzz parameter. + +

Mac OS X

+To build gcc and glibc on Mac OS X, you'll need to install a few gnu utilities: +
    +
  • gnu wget +
  • gnu awk +
  • gnu sed +
  • gnu install (part of gnu coreutils) +
+such that they are used instead of the native versions. (This may involve +setting PATH and/or making symbolic links.) +

+The way I installed them was using fink, +but DarwinPorts +or installing from tarballs would probably do as well. +

+One recurring problem is that various Gnu configure scripts assume that +'as' and 'ld' are the Gnu versions, run them with -v to get the +version number, and compare it with some gnu version. +That doesn't work well on the Mac. You can either hack the +configure scripts to not do that, or write wrapper scripts for +as and ld. For instance, here's a wrapper script for as that +blatantly lies about what version it is, just to make crosstool happy: +

+  test "$1" = -v && echo GNU assembler 2.13 || /usr/bin/as "$@"
+
+Nikolaus Schaller tied all the above into a tidy script; see his +build.sh +which both downloads the needed tools and creates the wrappers for as and ld. + +

+On some (older?) versions of Mac OS X, you'll need to raise the stack size with the command +

ulimit -s 8192
+else make may segfault. + +

+When using 2.6 kernel headers on systems (like Mac OS X) where gcc doesn't support the +-shared flag, you may see the error +

+gcc: unrecognized option `-shared'
+ld: Undefined symbols:
+_main
+make[1]: *** [scripts/kconfig/libkconfig.so] Error 1
+make: *** [oldconfig] Error 2 
+
+ +This is a well-known issue (see e.g. +Peter Samuelson's post of 7 Nov 2002 +Bertrand Marquis a patch that might help +on 29 June 2004. +It would be nice if someone figured out a patch +that could go into the mainline kernel sources to deal with this issue. +

+Another problem building Linux on Mac OS X is described, together with a Mac OS X specific workaround, by +Martin Schaffner's post of 22 May 2004. + +

Cygwin

+Crosstool, and probably gcc and glibc's configure scripts, assume that +directory names do not contain any spaces. +This is often violated on Windows. Please take care to not use +directory names with spaces in them when running crosstool. +It might work, but if it doesn't, you've been warned. +(Same goes for Mac OS X.) +

+crosstool creates some really deeply nested directories while building, +so filenames are quite long. This has two consequences: +

+First, on some versions of Windows, filenames (including directory) can't +be longer than 240 chars. To avoid exceeding this limit, don't run crosstool in +a directory with a long name. +

+Second, the maximum length of commandlines is extremely short. +Since crosstool uses commandlines that include multiple filenames, +they can exceed the limit very quickly. +You can avoid this problem by using the "mount" command's options. +e.g. mount /bin and /usr/bin with -X or "-o cygexec" (see the cygwin faq, +and/or mount the crosstool directory with "-o managed" (see the cygwin doc for "mount"). +

+Also, this isn't really a crosstool problem, but configuring linux-2.6 on cygwin may fail with the error +

+$ make menuconfig
+ HOSTCC  scripts/basic/fixdep
+ HOSTCC  scripts/basic/split-include
+ HOSTCC  scripts/basic/docproc
+ HOSTLD  scripts/kconfig/mconf
+collect2: ld terminated with signal 11 [Segmentation fault], core dumped
+
+A possible fix described e.g. +by Bertrand Marquis' post of 29 June 2004 +is to patch linux-2.6/scripts/kconfig/Makefile to just use libkconfig.o rather than first making a .so. +

+Cygwin-1.5.9-1 had a bug that prevents it from building glibc. +You can work around this by updating to Cygwin-1.5.10-2. + +

Solaris Build Considerations

+Crosstool ought to build on Solaris as long as it has been updated with +the appropriate set of GNU tools, but this has not been tested. +

+binutils-2.15 may require this patch +to work on Solaris, else it is said to segfault when building the Linux kernel. +

+glibc documents which GNU tools it requires in its INSTALL file. +The list is roughly: make 3.79, GCC 3.2, binutils 2.13, texinfo 3.12f, awk 3.0, sed 3.02, or newer. +gcc documents a few other requirements in gcc.gnu.org/install/specific.html, which +says that gcc won't build at all with the default solaris shell, and +you're supposed to work around it like this: +

+% CONFIG_SHELL=/bin/ksh
+% export CONFIG_SHELL
+
+before running crosstool. +

+That page also advises that you may need to install some Solaris patches, +and install gcc-3.2.3 or newer before trying to build newer versions of gcc. + +

Target Platform Notes

+

MIPS

+

Little-endian MIPS +

+To create a toolchain for the Linksys wrt54g, select glibc-2.2.3. +See LinksysWrt54g + wrt54g-linux.html +

+Note: recent wrt54g firmware uses uclibc, which behaves like a subsetted glibc. +There are patches to build uclibc toolchains in the contrib directory, +but they're not integrated yet. However, you can still use a glibc +toolchain; you'll either have to +

    +
  • not call the missing functions,
    • +
  • use a stub library like + libtivohack
    • +
  • link your programs statically if you want them to run on the + wrt54g.
    • +
+ +

SH3

+

+SH3 support is untested... it is said to build, and "hello, world" works, +but that's all I've heard. +

FIXME: The SH3 is supposedly the same as an SH4 +but without the floating point unit, so maybe glibc has to be built +--without-fp. See powerpc-405.dat and +Configuring and compiling GNU Libc + +

SH4

+

+Note: +

    +
  • binutils < 2.13 doesn't know about SH4, so don't try building + gcc-2.95.
    • +
  • gcc-3.2.3 has ICE compiling glibc for SH4 (PR6954), so +don't try building gcc-3.2.3.
    • +
+ +

CRIS

+

+CRIS doesn't build with glibc-2.3.2; +fails with "errno-loc.c:39: error: `pthread_descr' undeclared" in glibc build. +The cris glibc maintainer is aware of the problem and hopes to fix this later +in 2004, but we don't know if this has been done. + +

+We removed cris support, demo-cris.sh, from crosstool. If you need it, you may find it in the +previous version of crosstool. +

ARM-Xscale

+

+gcc-3.3 doesn't support this, need gcc-3.4 or later. + +

ARM-iwmmxt

+

+gcc-3.3 doesn't support this, need gcc-3.4 or later. + + + +

Troubleshooting

+ +

Download Problems

+all.sh calls getandpatch.sh, which looks in the directory specified by +TARBALLS_DIR for source tarballs, and downloads them to there if not found. +

+If the download hangs, and you need to use a proxy, +try telling wget about your proxy before running all.sh by doing +

+$ export http_proxy=<proxy_host>:<port>
+
+If the download still hangs, download the tarball that's causing the hang manually to +the directory specified by TARBALLS_DIR. + + +

Current Issues

+
    +
  • all.sh's --builduserland seems to be broken at the moment. +
  • NPTL is not yet supported. +
  • These scripts, unlike Bill Gatliff's original crossgcc scripts, +don't support bare metal newlib targets. They should, but I needed to +focus on targeting Linux first. See contrib/newlib for a user-contributed fix. +
  • These scripts don't support uClibc yet, but see below. +
  • The hppa target is not yet supported. +
  • glibc-2.3.2 doesn't build for cris; looks +like the maintainer needs to create a sysdep-cancel.h for cris. +I no longer try cris, since it seems to be unmaintained. +
+See the ChangeLog for more issues. + +

Build Status

+The script regtest-run.sh tries to build a number of combinations of gcc, glibc, and CPU, +and saves the last hundred or so lines of the build log in the file buildlogs$cpu-$gcc-$glibc.log.txt, +along with a summary of the build in the file buildlogs$cpu-$gcc-$glibc.dat.txt. +The script regtest-report.sh creates the file buildlogs/$version/index.html summarizing the results. +Note: this reflects whether the toolchains could be built, not whether they work! +Also note: running regtest-run.sh takes a LOT of cpu power, so +it uses ssh to spawn build jobs on multiple machines. Read the script carefully before running it. + +

Contributed Patches

+A few users of the crosstool scripts have submitted patches. I'm +saving these in the 'contrib' directory until I have time to test them. +
    +
  • testsetup - my scripts which are handy when running test suite remotely +
  • newlib, newlib2 - scripts to build newlib toolchains +
  • crosstool-uclibc-0.28-rc5.patch to build uclibc toolchains (see below) +
  • contrib/xtool-ro.patch lets you run with sources in a read-only directory. +
+ +

uClibc

+The script contrib/demo-uclibc.sh demonstrates how to patch an older version +of crosstool to support uclibc. This script, with editing, +can be used to build ARM7, PPC405, and maybe MIPS uclibc toolchains. +A future version of crosstool will merge the patch. + +

Links

+Patch repositories (handy if you are looking for a fix to a specific problem): + +There are many good general references for people building crosscompilers. Here is a somewhat outdated set: + + +Here are a few posts about which combinations of versions work: + + +Related Mailing lists (corrections welcome): + + +

+

+Portions copyright 2003, Ixia Communications
+Portions copyright 2003, 2004, 2005 Google
+Released under the GPL.
+Last revision 2 Mar 2006 by dank@kegel.com + + diff --git a/doc/embedded_lfs.odp b/doc/embedded_lfs.odp new file mode 100644 index 0000000..f0a26b2 Binary files /dev/null and b/doc/embedded_lfs.odp differ diff --git a/doc/qemu_to_vmware_image.html b/doc/qemu_to_vmware_image.html new file mode 100644 index 0000000..cddc642 --- /dev/null +++ b/doc/qemu_to_vmware_image.html @@ -0,0 +1,1198 @@ + + + + VMware Communities: Authorization Service not running. ... + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ + +
+ + + + +
    +
  • + +
    + + + + + + + +
    + +
+
    +
    • +
+ + + + + +
+ + +
+
+ + + + + +
+ + +
+ + + + + + + VMware Communities > + + VMTN > + + Desktop > + + VMware ACE > + + + + Discussions +
+ + + +
+ + + + + +
+ + + +
+ + +
+ +
+ + + + Previous + Next + + + + Up to Discussions in VMware ACE + +
+
+ + + + +
+ + + + + + + +
+ + +
+ +
+ + +
+
+ Actions + +
    +
+
+
+ + + + + + + + + + + + + +
+ +
+ + 		+ +
+
+ + + + + + + + + + +
+
+

This Question is + Possibly Answered +

+ 1 "correct" answer available (10 pts) + 2 "helpful" answers available (6 pts) + + +
+
+ + + + + + + + + 1 + 2 + + + Previous + Next + + + + + + + +
+ + + + + + + + +
+ + +
+ +
+
+ Reply + + Re: Authorization Service not running. Aug 20, 2007 9:56 AM +
+ +in response to: don Sjon + +
+
+
+
+ + + Click to view marcusaurelius's profile + Hot Shot + + +marcusaurelius 127 posts since
Feb 3, 2005 + VMware + + +
+ +
+ You mean you ran one of the .msi files, rather than "setup.exe" ?
+
+If so, I would expect you to run into problems. + + + + + +
+
+ +
+
+
+
+ + + + + + + +
+ + +
+ +
+
+ Reply + + Re: Authorization Service not running. Aug 20, 2007 10:43 PM +
+ +in response to: marcusaurelius + +
+
+
+
+ + + Click to view don Sjon's profile + Novice + + +don Sjon 12 posts since
Aug 7, 2007 + + +
+ +
+ there is/was only 1 msi file and a bunch of CAB files? + + + + + +
+
+ +
+
+
+
+ + + + + + + +
+ + +
+ +
+
+ Reply + + Re: Authorization Service not running. Aug 20, 2007 11:55 PM +
+ +in response to: don Sjon + +
+
+
+
+ + + Click to view marcusaurelius's profile + Hot Shot + + +marcusaurelius 127 posts since
Feb 3, 2005 + VMware + + +
+ +
+ Wait, are we talking about a deployed ACE instance? If so, there should be two MSIs and an EXE, assuming your deployment target is set for Windows hosts. For Linux there should be a PERL setup script and some other files. If that isn't what the package you're deploying looks like, I'd say there's a good chance the problem stems from this.
+
+Message was edited by:
+ marcusaurelius + + + + + +
+
+ +
+
+
+
+ + + + + + + +
+ + +
+ +
+
+ Reply + + Re: Authorization Service not running. Aug 28, 2007 6:39 AM +
+ +
+
+
+
+ + + Click to view Peppermint's profile + Lurker + + +Peppermint 1 posts since
Aug 28, 2007 + + +
+ +
+ If this problem exist you should disable the Windows Fast Logon Feature to make sure that the VMware Authorization Service is already started by the time you want to use VMware.
+
+You can do this by using the Group Policy Editor:
+
+1: Click Start > Run > and type gpedit.msc.
+
+2: Navigate to Computer Configuration > Administrative Templates > System > Logon > Always wait for the network at computer startup and Logon.
+
+3: Double-click the policy and select Enabled.
+
+4: Reboot
+
+OR...
+
+by editing the Registry:
+
+1: HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows NT\CurrentVersion\Winlogon\
+
+2: set the value SyncForegroundPolicy to 1; (REG_DWORD)
+
+3: Reboot + + + + + +
+
+ +
+
+
+
+ + + + + + + +
+ + +
+ +
+
+ Reply + + Re: Authorization Service not running. Oct 2, 2007 8:32 AM +
+ +
+
+
+
+ + + Click to view Earthbound's profile + Lurker + + +Earthbound 1 posts since
Apr 12, 2007 + + +
+ +
+
+My OS: Vista x64 w/ VMWS 6.01 (55017)
+

+I had this issue yesterday when I switched net cards. I found that on the new network card that the firewall was turned on by default so I turned it off (our network is behind 2 very robust firewalls so it is not needed on the local machine). I then proceeded to stop and restart all the VM services. Thanks to the tips here on the forum this was an easy fix. + + + + + +

+
+ +
+
+
+
+ + + + + + + +
+ + +
+ +
+
+ Reply + + Re: Authorization Service not running. Oct 2, 2007 9:51 PM +
+ +in response to: marcusaurelius + +
+
+
+
+ + + Click to view don Sjon's profile + Novice + + +don Sjon 12 posts since
Aug 7, 2007 + + +
+ +
+
+to marcusaurelius,
+

+sorry i missed your entry. Actually i'm mixing stuff now. I had this problem with my VMware workstation.
+

+ + + + + + +

+
+ +
+
+
+
+ + + + + + + +
+ + +
+ +
+
+ Reply + + Re: Authorization Service not running. Nov 25, 2007 4:06 AM +
+ +
+
+
+
+ + + Click to view Xingular's profile + Lurker + + +Xingular 1 posts since
Nov 25, 2007 + + +
+ +
+ Try running vmware in administrator mode. (Right click> Properties on the vmware workstation icon in the start menu. Set run as administrator under the compatibility tab). It should do the trick. + + + + + +
+
+ +
+
+
+
+ + + + + + + +
+ + +
+ +
+
+ Reply + + Re: Authorization Service not running. Dec 22, 2007 11:17 AM +
+ +
+
+
+
+ + + Click to view vmuser-1's profile + Lurker + + +vmuser-1 4 posts since
Dec 22, 2007 + + +
+ +
+
+Hi, guys
+

+I as using vmware ver5 on win-xp system till yerterday, but all of sudden i got the same error of vmware authorisation service failed
+I have tried to resolve this by uninstalling-re-installing the software, also tried by adding vm user in local admin group.
+for last try i also re-installed win-xp but that also doesn' work. so pls help me out!!!!!!!!! + + + + + +

+
+ +
+
+
+
+ + + + + + + +
+ + +
+ +
+
+ Reply + + Re: Authorization Service not running. Dec 22, 2007 2:52 PM +
+ +in response to: vmuser-1 + +
+
+
+
+ + + Click to view don Sjon's profile + Novice + + +don Sjon 12 posts since
Aug 7, 2007 + + +
+ +
+
+have you tried what was suggested before:
+
+
I had this problem with VMware workstation 5 and 6.
+I found this thread usefull:
+http://www.vmware.com/community/thread.jspa?messageID=183973
+
+So, To solve this I had to put the local user __vmware_user__ in the local administrators group.
+
+

+

+
+
+ + + + + + +
+
+ +
+
+
+
+ + + + + + + + 1 + 2 + + + Previous + Next + + + + +
+ + +
+
+ + +
+ + + + + +
+ + + +
+ +
+ + + + Previous + Next + + + + Up to Discussions in VMware ACE + +
+
+ + +
+ + +
+ + + + + + + + + +
+
+ + + +
+ + + + + + + diff --git a/doc/tutorial.txt b/doc/tutorial.txt new file mode 100644 index 0000000..68a7cad --- /dev/null +++ b/doc/tutorial.txt @@ -0,0 +1,390 @@ +Cross Compiling Linux - 2 hour tutorial + +This is a practical introduction to cross compiling, during which we'll build +a working cross-compiler, use it to cross-compile a native uClibc-based Linux +development environment, and boot this new environment under QEMU. + +Attendees may choose arm, mips, x86, x86_64, sparc, or PPC as the platform +they wish to build for. The author's Firmware Linux project (which already +does all this) will be used as an example. Attendees should bring a reasonably +fast laptop with net access and at least 256 megs of ram. + +General outline: + +1) Terminology: cross compiling, native compiling, host/target, toolchain, etc. +2) Why cross compiling is hard, and why we need to do it anyway. +3) Building a cross compiler toolchain from linux, binutils, gcc, and uClibc. +4) Making a native build environment (adding make, busybox, and bash). +5) Packaging disk images, booting, and running under QEMU. +6) Optimizations and alternatives. + (distcc, armulator, boards/bootloaders, nfs, tsrpm) +7) Where to from here? (LFS, gentoo, etc.) + + +----------------------------------------------------------------------------- +Links: + http://www.landley.net/writing/docs/cross-compiling.html + http://www.landley.net/code/firmware/about.html + http://www.landley.net/code/firmware/design.html + http://cross-lfs.org/files/BOOK/1.0.0/ + http://www.gentoo.org/proj/en/base/embedded/index.xml + http://gentoo-wiki.com/Embedded_Gentoo + +http://www.quietearth.us/articles/2006/08/16/Building-deb-package-from-source + +http://qemu-forum.ipi.fi/qemu-snapshots/ +git://git.kernel.dk/data/git/qemu.git +----------------------------------------------------------------------------- + +Today's agenda: + + - learn about cross compiling + - build a working cross-compiler + - use it to cross-compile a native uClibc-based Linux development environment + - boot this new environment under QEMU. + +Platforms: + - What platforms does Linux support? + - To get the full list: cd include; echo asm-* | sed 's/asm-//g' + - alpha arm arm26 avr32 cris frv generic h8300 i386 ia64 m32r + m68k m68knommu mips parisc powerpc ppc s390 sh sh64 sparc sparc64 um + v850 x86_64 xtensa + - Not quite architectures: generic=shared code, um=User Mode Linux + - What dominates the big iron space? + - Top 500 supercomputers list: http://top500.org/stats/28/procfam/ + x86-64 (44%), x86 (24%), and PPC (18%). + - Note: s390 important but not general purpose + - What dominates the embedded space? + - The big four: arm, mips, i386/x86_64, ppc. + - important but not general purpose: + - sh (super-hitachi) used in japan, especially in auto industry. + - coldfire (m68knommu): used in a small number of high volume devices. + - blackfin: up-and-coming, not merged yet. Employ interesting people. + - in decline (used to be more important) but still in use: + alpha, ia64, sparc, parisc. + + - price, power consumption, performance, features + - power consumption == heat, high end and low end converge due to this. + - features could be software or integrated peripherals. + + - close up on arm + - best power/performance ratio, owns over 80% of cell phone market. + - entire arm core only 43,000 transistors, 34 instructions. + - armv3 vs arm 7, architecture vs processor. We focus on architecture. + - armv3 introduced 32-bit, but obsolete. armv4 now low-end. + - most systems now being manufactured armv5 or up. + - newer runs older instructions. armv4->armv5 25% speedup for recompile. + - arm26 obsolete 26 bit addressing mode, like x86's 16-bit mode. + - can be LE or BE. Linux supports both, but only one at a time. + Chip doesn't care but motherboard might. + + - close up on mips + - customizable: sold as library, FPGA version, fab your own, used in SOC. + - there is now a 64 bit version. Probably for bragging rights. + - reasonable power consumption, reasonable performance. + - can be LE or BE. + + - close up on ppc + - can be LE or BE, long ago software selectable now almost universally BE. + - Apple/IBM/Motorola. Apple switched, Motorola spun off freescale. + - power.org attempt to stir up third party interest, some success. + - Game consoles give it serious volume, but Apple TV is x86-64. + - Models: + - Everything can run 7xx code except 4xx (ibm) and 8xx (motorola). + - 74xx is "G4", 970 is "G5" and is 64-bit. + - High power consumption, high performance + - Cell would have been very interesting if it had shipped in 2005, but + it's too late to matter outside gaming consoles now. Too much power + for embedded space, and big iron assembly programming specialized. + + - close up on x86/x86-64 + - Intel and AMD have stopped making non-embedded 32-bit processors. + - Once existing inventory sold, it's 64-bit only from here on out. + - A number of smaller players like via. + - Best price/performance, often best general purpose absolute performance + - Historically terrible power/performance, hence the fan. + - Recently paying attention to that, but a ways to go. On x86 a + fanless heat sink is a victory, whereas most arm runs cool to the touch. + +Compiling software for different platforms: + - Native compiling on different platforms: + - endianness, word size, alignment, sign of char, optimizations + - nommu is its own can of worms: stack, malloc, vfork, mmap + - x86 is the common case, but this changes to x86-64 soon. + - Neither intel nor amd making x86 outside of embedded space anymore. + Once current inventory sold, it's all 64-bit from here. + - cross compiling + - host and target are two contexts, most programs used to one. + - For most programs there is only one context: the target. Worrying about + host is the compiler's job, not yours. + - The compiler tells program what target it's building for with #defines + (__i386__, __arm__, __mips__) etc. + - To see all predefined symbols: gcc -dM -E - < /dev/null + - The headers specify endianness, #include + - confusing the two contexts: + - May have to build and run programs on host, ala menuconfig or unifdef. + - Need a host compiler for that, HOSTCC. + - Two compilers, keep track of which to use where + - ./configure asks questions about the machine it's building on to + determine what kind of program to build. Assumes host==target. + Fundamentally wrong for cross compiling, at the design level. + - two compilers (host and target), they get each other's files mixed up. + - #includes paths, library paths, gcc calls wrong ld... + - prefix the names, but this isn't complete ("collect2"). + - gcc falls back to "default" search path when it can't find something. + - gcc doesn't know where to find the files it installed. + + - Everybody cares about native compiling, nobody cares about cross compiling. + - Most projects don't care about cross compiling, and never will. + - gentoo over 4000 packages, gentoo embedded cross compiles maybe 300. + - Cross compiling complicates build system while restricting options, + this infrastructure is a source of bugs even when it's not used, and + only a tiny minority of the userbase will ever want it. + - Everybody cares about native compiling. + - If they don't, they'll probably take patches. + - simple to fix, non-intrusive, generally considered a good thing. + - Most developers don't know there's more to it than "build on arm". + + - Building natively on real hardware can be problematic + - 200 mhz, 32 megs of ram, only access through serial port + - We have one piece of real hardware and five developers. + + - But there are emulators, and desktops are cheap and powerful these days. + - Throwing hardware at the problem cheaper than developers. + - State of the art is QEMU, which is GPL. + + - A certain amount of cross compiling can't be avoided. + - where do you get your development environment from? + - bootstrap new platform. + - recent ubuntu desktop CD for little-endian mips? + + - So cross compile to bootstrap a native environment, then build natively + under emulation. + + - Trick: have the emulator call out to the cross compiler with distcc. + - ./configure, make, preprocessing, and linking all run native. + - heavy lifting of compilation farmed out, but that's hard to screw up. + +Firmware Linux Walkthrough. + - Prepare (download source, build some optional tools) + - Build cross compiler (cross-compiler.sh) + - Cross-compile native build environment (mini-native.sh) + - package this so qemu can run it + - Run it under qemu + - Build hello world natively. + +Build binutils. + Fairly straightforward, no target dependencies. + +Build gcc. + Needs a target version of binutils. + Pain in the ass because gcc is "special". + +Beating GCC into submission + - gcc is NOT SPECIAL. But it thinks it is. + - special case, special olympics, very special episode, isn't that special. + - Compiler turns input into output. So does a docbook to pdf converter. + - Explicit and implicit input files. + - xmlto has cmdline files, plus fonts and stylesheets. + - gcc has headers and libraries and such. + + - A compiler doesn't try to run the programs it's building. + - Reads C source, assembly, and ELF files. + - Outputs C source, assembly, ELF files. + - It reads and generates ELF and a.out as archive formats + - readelf, ar, ldd, nm, objdump, libbfd + - Not special. Just files. + + - In theory, all you have to tell GCC during ./configure is what target it + should produce binaries for. + - What host the resulting gcc you're building _runs_ on is determined by + the host compiler you're building gcc with, and it's got the same + __i386__ #defines as every other platform if it really wants details. + - That some compilers produce binaries that can be immediately executed + is sheer coincidence, nothing more. So can sed when it outputs a shell + script. + + - Targets are descirbed as tuples. + - What's a tuple? + - It's designed to conflate together several characteristics to reduce + orthogonality in the configuration. (No, this is not a good thing.) + Luckily, most of it doesn't apply to Linux. + - just append "-unknown-linux" to your architecture. + - armv4l, armv5l, mipsel, mips, sparc, powerpc, i686, x86_64 + - So nothing like the kernel's ARCH= values? + - Not really. + + - In practice, gcc wants to build itself with itself. + - No other compiler could possibly build a usable copy of gcc! + - gcc is _special_ + - so build a temporary version (xgcc) with the tainted other compiler, + then rebuild a _clean_ version with xgcc. + - That's not enough, it wants to build itself three times. + - 1) build xgcc, 2) rebuild, 3) rebuild with #2 and compare 2 & 3. + - Serious paranoia. Emotional scars. It was abused as a child. + - I'm sure the developers can tell us horror stories of platforms + where this was a vitally important safeguard. Those platforms were + not Linux. + - Dear gcc: you can't always get what you want. + + - This redundant build is not compatible with cross compiling. + - When gcc is making cross compiling, it can't do this crazy stuff + - Two vastly different build systems within the same project? + - But of course. It's from the FSF, where bigger is better. + - How do you tell it to produce a cross-compiler? + - When host and target differ, it behaves almost rationally. + --host=i686-unknown-linux --target=armv4l-unknown-linux + + - But what if I'm building for i686-uclibc target from i686-glibc host? + If gcc does the three-step, xgcc won't run because uclibc isn't + installed on the host. + - Lie to gcc, like so: + --host=i686-walrus-linux --target=i686-unknown-linux + - Then it thinks it's cross compiling, and will WORK. + + - The wrapper script: + - "pathological", adjective, "having to do with the path logic in gcc". + - gcc can't find files it installed. + - It searches in lots of different places using crazy paths with lots + of "subdir/../../../newdir" in them. Run it under strace sometime, + it's frightening. + - Paths from environment variables, paths from built-in spec files, + paths supplied from ./configure, paths added on the command line, + paths hardwired into the C code... + - Every time the previous layer bit-rots to the point of collapse, + they add yet another layer. They never _remove_ anything, they + just stick it at the front of the list and fall back to looking + in all the other locations when they can't find it. + - All this is based on an absolute path from the root, hardwiring + into the gcc binary the path to the directory gcc was built in. + (What if you want to install a toolchain into your home directory, + without needing root access?) + - At the end it falls back to default locations like /usr/include + which contains host stuff, not target stuff. + - If it can't find the headers or libraries it needs, it happily + substitutes the ones out of the host compiler. THIS IS WRONG. + + - How to we untangle this? + + - gcc has seven important sources of input (spec files don't count): + - Explicit input (C files listed on the command line) + - system library headers + - #include stdio.h. From libc, zlib, etc. + - default is /usr/include + - compiler headers + - #include stdarg.h, for va_arg and such. + - default looks like /usr/lib/gcc/i486-linux-gnu/4.1.2/include + - system libraries + - libc.so, libz.so, libncurses.so.5.5 + - search path, includes /lib:/usr/lib and elsewhere. + - try ldd /bin/ls + - note .a vs .so vs .so.6 + - compiler libraries + - libgcc_s.so (is evil). + - stack unwinding, divide by long on 32-bit platforms, soft float... + - at compile time, /usr/lib/gcc/i486-linux-gnu/4.1.2 + - at run time libgcc_s.so is in /lib + - Executable search path + - In theory so gcc can call ld. + - in practice, collect2 and cc1 because gcc is bloated. + - You'd think this would use $PATH, but that would be too easy. + - Install binaries in $PATH? But I'm _SPECIAL_ + + - Bypass gcc's path logic entirely. It's the only way to be sure. + - Wrapper, parse gcc command line, call gcc with --nostdinc and + --nostdlib (so it won't fall back to leaking in host stuff), + explicitly specify header and library search paths (since we know + where they are), and edit $PATH so it can call ld and such. + - While we're at it, specify the location of the shared library loader. + - Not actually used at compile time, just written into the binary to + be used at runtime. But it's something else we need to get right + to make usable binaries. + + - Hang on, if we've got a wrapper why do we need to recompile for the + i686-glibc to i686-uClibc case? + - Because libgcc_s.so links against glibc, thus leaking a reference to + the wrong C library. (Thanks gcc!) If we rebuild libgcc_s.so against + uClibc, it's at least leaking a reference to the right library. (Or + better yet, configure gcc with --disable-shared so it has libgcc.a + instead and doesn't do this at all.) + + - Ok, that was the hard part. It's all downhill from here. + +So back to bootstrapping a toolchain. + Binutils builds by itself with no dependencies on other target packages. + gcc needs a target version of binutils + gcc also needs a wrapper script (or _extensive_ patching) to have sane + path logic, but the wrapper script has no dependencies on anything else. + uclibc needs: + a gcc for the target + linux kernel headers for the target (but the kernel headers have no + dependencies and can be installed first). + + - start with binutils, wrapper, and/or linux kernel headers. + - gcc comes after binutils. + - uClibc comes after gcc and kernel headers. + +Now build a native build environment for the target. + In theory, you could follow Linux From Scratch from this point on. + In practice, a minimal development environment only needs seven packages: + binutils, gcc, kernel (headers _and_ vmlinux this time), uClibc, + busybox, make, bash. + (Why bash? Busybox shell isn't good enough yet.) + - might have been fixed in newer versins, I don't follow it anymore. + From that, you can build an entire Linux From Scratch system. + I spent ~3 years fixing up busybox to the point where it works for this. + + In theory, the smallest self-bootstrapping system would be four packages: + Linux, uclibc, busybox, tcc. + But that doesn't work yet. :) + +How do you build a native compiler for another platform? + Build twice: + Use your host compiler to build a compiler targeting the platform. + This runs on the host to produce target binaries, so it's a + cross compiler. + Use the cross compiler to build a compiler targeting the platform. + This runs on the target to produce target binaries, so it's a + native compiler for the target. + Technically, this is called a "canadian cross". + - They had to come up with a special name for it. It's NOT SPECIAL. + - Your cross compiler could target one platform and the second compiler + could target another, so you could use your x86 machine to build a + cross compiler that runs on sparc and outputs arm binaries. So what? + - This is what gcc is doing internally anyway if you tell it + --host arm and --target arm on your x86 machine. Except in _that_ + case it wants to know --build. Why? Don't go there. + +General outline: + +1) Terminology: cross compiling, native compiling, host/target, toolchain, etc. + +2) Why cross compiling is hard, and why we need to do it anyway. + +3) Building a cross compiler toolchain from linux, binutils, gcc, and uClibc. + Bootstrapping issues, what depends on what? + +4) Making a native build environment (adding make, busybox, and bash). + Building a new system. + +5) Packaging disk images, booting, and running under QEMU. + +6) Optimizations and alternatives. + (distcc, armulator, boards/bootloaders, nfs, tsrpm) + +7) Where to from here? (LFS, gentoo, etc.) + + +----------------------------------------------------------------------------- +Links: + http://www.landley.net/writing/docs/cross-compiling.html + http://www.landley.net/code/firmware/about.html + http://www.landley.net/code/firmware/design.html + http://cross-lfs.org/files/BOOK/1.0.0/ + http://www.gentoo.org/proj/en/base/embedded/index.xml + http://gentoo-wiki.com/Embedded_Gentoo + +http://www.quietearth.us/articles/2006/08/16/Building-deb-package-from-source + +http://qemu-forum.ipi.fi/qemu-snapshots/ +git://git.kernel.dk/data/git/qemu.git diff --git a/doc/uclibc-bootfloppy.txt b/doc/uclibc-bootfloppy.txt new file mode 100644 index 0000000..6dd4eff --- /dev/null +++ b/doc/uclibc-bootfloppy.txt @@ -0,0 +1,667 @@ +AUTHOR: Csaba Henk + +DATE: 2003-10-27 + +LICENSE: The MIT License + +SYNOPSIS: Making an uClibc-based bootfloppy + +PRIMARY URI: http://www.math-inst.hu/~ekho/lowlife/ + +DESCRIPTION: +This hints shows how to create a cutting-edge bootfloppy from scratch, +based on uClibc, a lightweight C library. + +PREREQUISITES: +This hint should be useable on any not too aged Linux installation with +a non-broken toolchain. It was tested on a (by and large) LFS-4.0 +system. The sudo utility is advised to have. + +ATTACHMENTS: +http://www.linuxfromscratch.org/hints/downloads/attachments/uclibc-bootfloppy/busybox-0.60.5-Config.h +http://www.linuxfromscratch.org/hints/downloads/attachments/uclibc-bootfloppy/linux-2.4.22-.config +http://www.linuxfromscratch.org/hints/downloads/attachments/uclibc-bootfloppy/mkbootdisk +http://www.linuxfromscratch.org/patches/downloads/devfsd/devfsd-1.3.25-uclibc-1.patch + +HINT: + +Contents +-------- + +Preface +Introduction +What do we need? +The concept +Setting up the development environment +Compiling the linux kernel +Installing uClibc on the development platform +Creating the root filesystem +Installing uClibc for the bootdisk +Installing busybox +Installing gpm +Other programs +Creating the bootdisk +Bugs and weirdnesses, todo + +Preface +------- + +* This hint is co-developed with the svnc-thinclient hint in the +framework of the lowlife project, + +http://www.math-inst.hu/~ekho/lowlife/ + +This file belongs to lowlife-0.5.1. + +* For the most recent version check out + +http://www.math-inst.hu/~ekho/lowlife/uclibc-bootfloppy.txt + +* Comments, ideas, critics, flames are welcome. + +* (If you are an LFS user, you can skip this.) Although this document is +formally an LFS hint, you can see use of it without knowing what LFS is +(I tried to write it keeping this possibility in mind). Anyway, I +recommend you to check out what LFS is. If you are not familiar with +compiling source code in unix/linux environment, then there is no use of +going on without checking out what LFS is. Consult the following docs +first: + +http://www.linuxfromscratch.org/lfs/whatislfs.html +http://www.linuxfromscratch.org/faq/ +http://www.linuxfromscratch.org/hints/downloads/files/essential_prereading.txt +http://www.linuxfromscratch.org/lfs/view/stable/preface/prerequisites.html + +Introduction +------------ + +When you are to put together a Linux bootfloppy, you need to decide what +implementation of the standard C libraries will you use. + +One possibility is using the C library implementation which is common on +Linux based systems: glibc. It's advantage is that you have it at hand: +to make a glibc-based bootfloppy, the only thing you have to do is to is +to copy the necessary libs to the filesystem you will put on the floppy. +This is way chosen by the rescue floppy described in the BLFS-book: + +http://linuxfromscratch.org/blfs/view/test/postlfs/bootdisk.html + +However, glibc is far from being lightweight, and eats up much of the +rather limited space you have when working with a floppy. So you might +like seek for an alternative which suits much better to the capabilities +of the floppy environment. + +Here we will create a bootfloppy based on the uClibc C library, which is +just made for such purposes. + +The bootfloppy will be cutting edge: uses uClibc and Busybox which are +actively developed projects for the embedded platform. Moreover, I used +a kernel from the 2.4.* branch (but feel free to use other kernel +releases). It is a good question to ask whether this is useful: many floppy +distros use older kernels for reducing resource usage. I can say the +following: on the one hand, I can afford using a recent kernel as my +bootfloppy merrily runs on my 486 with 8M RAM; on the other hand, from +the moment I began to use this up-to-date stuff, the problems with handling +the terminal buffer and plip timeouts vanished. So unless you are really +tight in resources, I think using a recent kernel is a good idea. + +We will also use some kind of development environment, just to stay on +the safe side. + +This hint has a continuation: there we will describe how to install the +svga vncviewer on the bootfloppy, which then becomes capable of turning a +machine to an X terminal. (Check out the svnc-thinclient hint: + +http://www.linuxfromscratch.org/hints/downloads/files/svnc-thinclient.txt +http://www.math-inst.hu/~ekho/lowlife/svnc-thinclient.txt + +) + +Additional info and downloadable bootdisk image with svnc can be found +at the lowlife homepage (or at its mirror): + +http://www.math-inst.hu/~ekho/lowlife/ +http://www.personal.ceu.hu/students/01/Csaba_Henk/lowlife/ + +In this hint the assumption of using an x86 PC (both for making and +booting the floppy) and gcc is set. You may try to port it to another +architecture / compiler. Doing it on another architecture should not +be hard. Doing it with another compiler depends on how much does +uClibc support that compiler. + +If you copy command from this hint to your shell, be careful that +line-terminating backslashes (\) keep their position (no whitespace +characters should follow them). A possible solution is open this hint in +the Vim GUI, and copy'n'paste from there. + +What do we need? +---------------- + +We will need the following programs; in general, most recent stable +versions are recommended. Those programs where I have a certain +important comment on the version are marked with (!) and you can find +the comment at the beginning of the respective install instructons. + +* Addons for the development platform: + +sudo (optional) + ftp://ftp.sudo.ws/pub/sudo/ + +* Programs for the bootfloppy: + +linux-2.4.* (!) + http://www.kernel.org +uClibc + http://www.uclibc.org/downloads/ +busybox-0.60.5 (!) + http://www.busybox.net/downloads/ +gpm (optional) + ftp://arcana.linux.it/pub/gpm + +The concept +----------- + +In LFS, bootstrapping a linux system goes in the following fashion: one +first installs kernel headers, then builds a toolchain against these +headers, finally builds a kernel using the shiny new toolchain. + +We don't need to produce a new toolchain: we will use the one of the +host distro (to which we'll refer as "development environment") (though +when making the userspace of our tiny linux system, we will access that +toolchain via the uClibc wrappers). + +This lets us to proceed in a much simpler way: first we compile the +kernel, then build uClibc using the headers of this kernel, finally +build the userspace against uClibc. + +We will use optimization for size (we'll pass the -Os flag to gcc). In +general you can delete sources after compilation if there is no specific +reasons to keep them. In those cases when you should *not* delete the +source I'll tell about it explicitly. + +Setting up the development environment +-------------------------------------- + +We definitely need some kind of development environment to protect +us from mucking up our system; eg., if we are in the file system +which we will put on the floppy, it is very easy to mistake usr with +/usr, and without such a protection, you can imagine that this +mistake can have serious consequences... + +We will create a non-privileged user named bootdisk for doing the +job. First choose a home directory for bootdisk and store this value +in $BDISKHOME. Then type: + +groupadd bootdisk && +useradd -g bootdisk -s /bin/bash -d $BDISKHOME bootdisk && +mkdir -p $BDISKHOME && +cat > $BDISKHOME/.bash_profile << "EOF" +export CFLAGS=-Os +export PATH=/usr/i386-linux-uclibc/bin/:$PATH:$HOME/bin +export CC=i386-uclibc-gcc +EOF + +Of course, you may specify more cflags, like -march=i486. The above +setting of the $PATH variable assumes that the usual directories to +be contained in the path are already set in /etc/profile. + +So the idea is that we will work as user bootdisk; however, there are +some tasks during the bootdisk creation which require a privileged user +-- namely, mounting ext2 files and raw-copying to a floppy. + +We can do two things about this problem: + +1) Ignore it, and execute these tasks as root. + +2) Make a script named mkbootdisk for doing this tasks. This script must +be executable only by root (mode 744). With the help of the sudo utility +we let the bootdisk user to use this script as well. That is, we put it +to $BDISKHOME/bin and then type: + +echo " +bootdisk ALL = NOPASSWD: $BDISKHOME/bin/mkbootdisk" >> /etc/sudoers + +A realization of mkbootdisk can be found as an attachment of this hint +at + +http://www.linuxfromscratch.org/hints/downloads/attachments/uclibc-bootfloppy/ + +or at + +http://www.math-inst.hu/~ekho/lowlife/mkbootdisk + +or in the current directory if you read this hint as a file of the +lowlife tarball avaliable at + +http://www.math-inst.hu/~ekho/lowlife + +Typing "mkbootdisk -h" will print a brief information on usage. + +We have the desired environment. We go on compiling the programs. Become +user bootdisk: + +su - bootdisk + +In the rest of the hint we will act as user bootdisk, with the following +exceptions: + +* as uClibc will be installed systemwise, you should install it as root; + +* if you don't use a mkbootdisk script, then the appropriate actions +are to be done as root; + +* doing a chroot test of your filesystem for the floppy is possible only +as root. + +This means that if you use a mkbootdisk script, then those steps of +creating the bootfloppy which shouldn't affect your development +platform, *can't* affect the development platform (provided your +mkbootdisk script doesn't do anything weird, which I think is +fulfilled by the one written by me). + +Some of the commands below assume that the actual source archive is +decompressed in $HOME (which is the same as the prior $BDISKHOME). +Software installation instructions always start at the point when the +source tarball is already decompressed and you entered the source +directory (unless we explicitely claim to act differently). + +Compiling the linux kernel +-------------------------- + +At the moment the latest stable release of the linux kernel belong to +the 2.4.* branch, but 2.6.0-test* releases are already out. This +situaton might change any time by the release of linux-2.6.0. The +following instructions regard to the 2.4.* releases; if you want to try +linux-2.6.*, not only the kernel compilation instructions but the whole +bootdisk creation procedure is to be revised (eg., you can't boot a +2.6.* kernel without a boot loader). After linux-2.6.0 will be out I +might consider to upgrade this hint to that version. + +We will compile a network-aware kernel optimized to size. I don't give +a complete reference, I just highlight some crucial points.If you need +not network-awareness, you may omit TCP/IP netowrking and network +drivers; but even in this case it is strongly recommended to include +"Unix domain sockets". + +In the kernel source tree type: + +sed -e 's%-O2%-Os%g' -e '/^CFLAGS_KERNEL/s%\(^.*$\)%\1 -Os%' Makefile > \ + Makefile.tmp && +mv Makefile.tmp Makefile + +The above commands set optimization for size in the Makefile. Edit the +Makefile if you want further optimizations. + +Now you should configure the kernel with "make menuconfig". Choose +carefully the value in the "Processor type and features ---> Processor +family" menupoint. When choosing options, it is advised to include only +those features you really need. Some important ones: + +Networking options ---> + <*> Unix domain sockets + [*] TCP/IP networking + +In the "Network device support --->" menupoint choose those network +drivers you intend to use. If you want to use plip, choose it as a +module, and also set: + +Parallel port support ---> + <*> Parallel port support + PC-style hardware + +This is advised because of the following: as I experienced, if no +option is given, the kernel initializes the parallel port (PC-style) +IRQ-less! At boot time we won't have the possibility to pass options +to the kernel, as we won't use a boot loader or initrd. Thus we can +set the appropriate IRQ value only if we load the parallel port +driver as module. Also, to gain more control over the NIC drivers, +consider building them as modules. + +In this hint we use the devfs facility, so choose + +File systems ---> + [*] /dev file system support + [*] Automatically mount at boot + +(See a more detailed description in the devfs hint: + +http://www.linuxfromscratch.org/hints/downloads/files/devfs+kernel_modules.txt + +). + +And don't forget to include support for the mouse type you will use with +the bootfloppy (if you will use any). + +OK, one more remark. Here I don't digress on how to use initrd, but you may +have some reason for doing that. In this case with some kernels (eg., with +linux-2.4.22) you might encounter with booting problems, which can be cured +by the appropriate kernel patch. For info on initrd and the patch you can +consult the "Creating a Custom Boot Disk" chapter of the BLFS-book, +referenced in the Introduction. + +Now compile the kernel with the + +make dep && make bzImage && make modules + +commands. Then type + +mkdir $HOME/rfloppy/lib/modules + +and copy the NIC driver modules from the drivers/net directory to +$HOME/rfloppy/lib/modules, and also the other modules you built. Eg., if +you use plip, you will need the drivers/parport/parport_pc.o +module. + +Do not delete the kernel source. + +If you have troubles with configuring the kernel properly, my .config file +might be of your help: + +http://www.linuxfromscratch.org/hints/downloads/attachments/uclibc-bootfloppy/ +http://www.math-inst.hu/~ekho/lowlife/linux-2.4.22/.config + +Installing uClibc on the development platform +--------------------------------------------- + +Usually we will optimize to size; in case of uClibc it's done +automatically. + +We install uClibc systemwise, thus the commands of this installation are +to be executed as root. + +In the uClibc source tree type + +make menuconfig + +uClibc now has a configuration interface similar to that of the linux +kernel. Apply the following settings: + +Target Architecture Features and Options ---> + ($BDISKHOME/) + Linux kernel header location +Library Installation Options ---> + (/lib) Shared library loader path + +This was enough for uClibc-0.9.19; in case of uClibc-0.9.21 we also need +the following: + +General Library Settings ---> + [ ] Support gprof profiling +String and Stdio Support ---> + [*] Support sys_siglist[] (bsd-compat) + +[Explanation: with profiling support set, uClibc wasn't willing to build +for me. The sys_siglist[] support will be needed by busybox which +encorporates some BSD code by having ash as its shell.] + +(Other uClibc versions may have their own gotchas.) + +Apart from this, the default configuration is quite suitable, probably +you need not change anything (especially you need not use full math +support). However, taking a look at the options never hurts; eg., you +may consider fine-tuning the target processor type. After you exit, + +make && +make install + +Further on we assume that you installed uClibc into +/usr/i386-linux-uclibc/ (the default installation location). + +Creating the root filesystem +---------------------------- + +We will put the files of the root filesysem of the floppy to a directory +named rfloppy. Firstly we create the directory and a basic tree of +subdirectories which vaguley resembles the FHS idea: + +cd && +mkdir -p rfloppy/{dev,proc,etc/init.d,sbin,bin,lib,mnt,usr,var/log} && +cat > rfloppy/etc/init.d/rcS << "EOF" && +#!/bin/sh +mount proc /proc -t proc +EOF + +The etc/init.d/rcS file will be the startup script for the floppy. Put +there what you want to be done in the beginnig -- eg., syslogd, klogd, +loading modules, starting gpm, etc. + +A very minimal etc directory is used in this setup. Enriching it (with +files like passwd, group, fstab, modules.conf, and so on) is up to you +-- this minimalist solution works anyway. + +Installing uClibc for the bootdisk +---------------------------------- + +We copy the necessary libraries of uClibc to the bootdisk. + +cp -a /usr/i386-linux-uclibc/lib/{ld-uClibc*,libc.so.0,libuClibc-*} \ + ~/rfloppy/lib + +Installing busybox +------------------ + +At the moment busybox has two branches: the development branch +(1.00-pre* releases) and the stable branch (0.60.* releases), but this +situation might change any time by busybox-1.00 being released. The +following instructions regard to the 0.60.* versions. The 1.00-pre* +versions differ greatly (encorporate much more utilities, eg.), so if +you go experimenting with them, these instructions probably need to be +changed. When the now-devel branch get stable (1.00 comes out), this +document will probably be upgraded to that version of busybox. + +Before making it, adjust the Config.h file according to your needs. To +make busybox work with devfs, be sure that the + +#define BB_FEATURE_DEVFS + +line is uncommented (not prefixed with "//"); and it is advised to +enable standard Unix utilities, moreover if you want to use network with +the floppy, consider uncommenting: + +#define BB_IFCONFIG +#define BB_TELNET +#define BB_TFTP +#define BB_FEATURE_IFCONFIG_STATUS + +Then install it with + +make CROSS=i386-uclibc- && +make PREFIX=$HOME/rfloppy install + +If you have troubles with configuring busybox properly, my Config.h file +might be of your help: + +http://www.linuxfromscratch.org/hints/downloads/attachments/uclibc-bootfloppy/ +http://www.math-inst.hu/~ekho/lowlife/busybox-0.60.5/Config.h + +Installing gpm +-------------- + +Having mouse at the console is not necessary, but very comfortable for a +bootfloppy as well. If you want it, install gpm by running the following +commands: + +./configure && +LDFLAGS="-lm" make && +strip src/gpm && +mkdir -p $HOME/rfloppy/{usr/sbin,var/run} && +cp src/gpm $HOME/rfloppy/usr/sbin && +cp -a /usr/i386-linux-uclibc/lib/{libm-*,libm.so.0} ~/rfloppy/lib + +[The /var/run directory is needed for gpm at runtime.] + +Other programs +-------------- + +Now if there is anything more you want to have on the floppy, compile it +and put it to the appropriate place under $HOME/rfloppy. A list of some +possible extensions: + +* devfsd ( + +http://ftp.kernel.org/pub/linux/daemons/devfsd/ + +) is not necessary for the bootfloppy, devfs work fine without it. So +install it only if you know what you are doing. However, it needs to be +hacked to get it compiled against uClibc. There is a patch for devfsd at: + +http://www.linuxfromscratch.org/patches/downloads/devfsd/devfsd-1.3.25-uclibc.patch + +or at + +http://www.math-inst.hu/~ekho/lowlife/patches/devfsd-1.3.25-uclibc.patch + +(or in the patches directory if you read this hint as a file of the lowlife +tarball) and you can find some explanation on it at + +http://www.math-inst.hu/~ekho/lowlife/ + +Note that devfsd depends on the libdl.so.0 library of uClibc (which is a +symlink to libdl-0.9.*.so). You have to put these to the /lib of your +filesystem. + +* The svnc-thinclient hint tells you how to compile and install svgalib +and the svga vncviewer to the floppy, giving the bootfloppy the +capabilities of an X terminal. + +The (functionality of the) following utilities are already encorporated +in the development versions of busybox. + +* You can put tinylogin ( + +http://tinylogin.busybox.net/ + +) to the floppy if you want a correct login system on it (with the +configuration described in this hint you just get a prompt after +booting). + +* You can put utelnetd ( + +http://www.pengutronix.de/software/utelnetd_en.html + +) to the floppy if you want to access it remotely. However, don't forget +that communication is not encrypted under telnet! + +* One more useful program is hdparm ( + +http://ftp.ibiblio.org/pub/Linux/system/hardware + +): if you boot with this floppy, the harddisk is probably not used, but +still is a source of noise by its spinning. You can stop it with +hdparm. (See its -y option.) + +Creating the bootdisk +--------------------- + +Before creating the floppy, you may wish to test the proposed filesystem +by chrooting to it; if so, execute as root: + +chroot $BDISKHOME/rfloppy /bin/sh + +Typing this you get the prompt of the busybox shell, and you should be +able to run those utilities which do not require much I/O (ls, cat, +echo,...). Proceed on again as the bootdisk user. + +Put a floppy to the floppy drive (if you are not sure about its +integrity, you might want to run fdformat on it). If you use my +mkbootdisk script, check whether the device name of the floppy drive is +set correctly in the script (it is set to /dev/fd0 and no option can +change it, in order to prevent the bootdisk user in being able to muck +up the development platform), and whether the $MKE2FSAPP, $RDEVAPP +variables in the script store the correct path to the mke2fs, rdev +utilities in your system (they should if you follow standards). If +everything is fine, simply run + +cd && +sudo mkbootdisk + +If you don't use the mkbootdisk script, become root, store the name of +your floppy device (typically /dev/fd0) in the variable $DISK. Now its +time to find out how big the root filesystem of the floppy should be, +and how much inodes should it have. Concerning the size, I think the +size of the stuff in the rfloppy directory + 150k is enough; concerning +the number of inodes, I think the number of files in rfloppy + 100 is +enough. But you should know. Store the chosen filesystem size in the +variable $SIZE (the number of kilobytes), and the chosen number of +inodes in the variable $INODES. Then type the following: + +cd $BDISKHOME && +# We we create and compress the root filesystem of the floppy: +dd if=/dev/zero of=rootfs bs=1k count=$SIZE && +yes | mke2fs -m 0 -N $INODES rootfs && +mkdir -p loop && +mount rootfs -o loop loop && +rmdir loop/lost+found && +cp -a rfloppy/* loop && +chown -R 0:0 loop/* && +umount loop && +dd if=rootfs bs=1k | gzip -v9 > rootfs.gz + +Now check whether rootfs.gz and your kernel image (probably +linux-2.4.*/arch/i386/boot/bzImage) fit on a floppy together (a floppy +is of 1440k usually but it can be formatted to bigger sizes as well). If +everything is fine, go on: + +# We copy the kernel to the floppy: +let KERNELSIZE=`dd bs=1k of=$DISK < linux-2.4.*/arch/i386/boot/bzImage 2>&1 | + sed -n '1s%\([0-9][0-9]*\).*%\1%p'`+1 && +# We perform some adjustments on the kernel copied to the floppy: +rdev $DISK 0,0 && +rdev -R $DISK 0 && +rdev -r $DISK `expr 16384 + $KERNELSIZE` && +# Finally we copy the compressed filesystem to its appropriate place \ +# on the floppy: +dd if=rootfs.gz of=$DISK bs=1k seek=$KERNELSIZE + +[Explanation -- also for those who wonder how the mkbootdisk script +works + +"yes | mke2fs -m 0 -N $INODES rootfs": + +This pipe construct is a common trick for answering stupid questions +non-interactively. + +"# We copy the kernel to the floppy" : + +In the command after this comment we not only copy the kernel to floppy, +but we also store the number of transferred kb's in the variable +$KERNELSIZE. + +"# We perform some adjustments on the kernel copied to the floppy" : + +We won't have a bootloader to tell the kernel where to find its root +filesystem. The commands after this comment set some specified bits +in the kernel, thus hardwiring the location of the root filesystem to +it: firstly, we tell the kernel to seek for the filesystem in the +floppy, secondly, we tell the kernel that a ramdisk is to be made and +the filesystem is to be decompressed to it, thirdly, we tell the +kernel the location of the filesystem within the floppy. The number +16384 = 2^14 is used for shifting within the range of bits in the +kernel devoted for describing these data. For more information +consult with the Bootdisk HOWTO available at tldp.org. + +"# Finally we copy [...]" : + +In the dd command after this comment we use the seek option to copy the +compressed filesystem nicely after the kernel image.] + +Now you have the floppy, boot & enjoy! + +Bugs and weirdnesses, todo +-------------------------- + +This hint is co-developed with the svnc-thinclient hint in the framework +of the lowlife project. These informations can be found in the svnc-thinclient +hint. + +ACKNOWLEDGEMENTS: + +This hint is co-developed with the svnc-thinclient hint in the framework +of the lowlife project. These informations can be found in the svnc-thinclient +hint. + +CHANGELOG: + +This hint is co-developed with the svnc-thinclient hint in the framework +of the lowlife project. These informations can be found in the svnc-thinclient +hint. -- cgit v1.2.3-54-g00ecf