1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
|
Toybox: all-in-one Linux command line.
--- Getting started
You can download static binaries for various targets from:
http://landley.net/toybox/bin
The special name "." indicates the current directory (just like ".." means
the parent directory), and you can run a program that isn't in the $PATH by
specifying a path to it, so this should work:
wget http://landley.net/toybox/bin/toybox-x86_64
chmod +x toybox-x86_64
./toybox-x86_64 echo hello world
--- Building toybox
Type "make help" for build instructions.
Toybox uses the "make menuconfig; make; make install" idiom same as
the Linux kernel. Usually you want something like:
make defconfig
make
make install
Or maybe:
LDFLAGS="--static" CROSS_COMPILE=armv5l- make defconfig toybox
PREFIX=/path/to/root/filesystem/bin make install_flat
The file "configure" defines default values for many environment
variables that control the toybox build; if you set a value for any of
these, your value is used instead of the default in that file.
The CROSS_COMPILE argument above is optional, the default builds a version of
toybox to run on the current machine. Cross compiling requires an appropriately
prefixed cross compiler toolchain, several example toolchains are available at:
http://landley.net/aboriginal/bin
For the "CROSS_COMPILE=armv5l-" example above, download
cross-compiler-armv5l.tar.bz2, extract it, and add its "bin" subdirectory to
your $PATH. (And yes, the trailing - is significant, because the prefix
includes a dash.)
For more about cross compiling, see:
http://landley.net/writing/docs/cross-compiling.html
http://landley.net/aboriginal/architectures.html
For a more thorough description of the toybox build process, see
http://landley.net/toybox/code.html#building
--- Using toybox
The toybox build produces a multicall binary, a "swiss-army-knife" program
that acts differently depending on the name it was called by (cp, mv, cat...).
Installing toybox adds symlinks for each command name to the $PATH.
The special "toybox" command treats its first argument as the command to run.
With no arguments, it lists available commands. This allows you to use toybox
without installing it. This is the only command that can have an arbitrary
suffix (hence "toybox-armv5l").
The "help" command provides information about each command (ala "help cat").
--- Configuring toybox
It works like the Linux kernel: allnoconfig, defconfig, and menuconfig edit
a ".config" file that selects which features to include in the resulting
binary. You can save and re-use your .config file, although may want to
run "make oldconfig" to re-run the dependency resolver when migrating to
new versions.
The maximum sane configuration is "make defconfig": allyesconfig isn't
recommended for toybox because it enables unfinished commands and debug code.
--- Creating a Toybox-based Linux system
Toybox is not a complete operating system, it's a program that runs under
an operating system. Booting a simple system to a shell prompt requires
three packages: an operating system kernel (Linux*) to drive the hardware,
one or more programs for the system to run (toybox), and a C library ("libc")
to tie them together (toybox has been tested with musl, uClibc, glibc,
and bionic).
The C library is part of a "toolchain", which is an integrated suite
of compiler, assembler, and linker, plus the standard headers and libraries
necessary to build C programs. (And miscellaneous binaries like nm and objdump.)
Static linking (with the --static option) copies the shared library contents
into the program, resulting in larger but more portable programs, which
can run even if they're the only file in the filesystem. Otherwise,
the "dynamically" linked programs require the library files to be present on
the target system ("man ldd" and "man ld.so" for details).
An example toybox-based system is Aboriginal Linux:
http://landley.net/aboriginal/about.html
That's designed to run under qemu, emulating several different hardware
architectures (x86, x86-64, arm, mips, sparc, powerpc, sh4). Each toybox
release is regression tested by building Linux From Scratch under this
toybox-based system on each supported architecture, using QEMU to emulate
big and little endian systems with different word size and alignment
requirements. (The eventual goal is to replace Linux From Scratch with
the Android Open Source Project.)
* Or something providing the same API such as FreeBSD's Linux emulation layer.
--- Presentations
1) "Why Toybox?" talk at the Embedded Linux Conference in 2013
video: http://youtu.be/SGmtP5Lg_t0
outline: http://landley.net/talks/celf-2013.txt
linked from http://landley.net/toybox/ in nav bar on left as "Why is it?"
- march 21, 2013 entry has section links.
2) "Why Public Domain?" The rise and fall of copyleft, Ohio LinuxFest 2013
audio: https://archive.org/download/OhioLinuxfest2013/24-Rob_Landley-The_Rise_and_Fall_of_Copyleft.mp3
outline: http://landley.net/talks/ohio-2013.txt
3) Why did I do Aboriginal Linux (which led me here)
260 slide presentation:
https://speakerdeck.com/landley/developing-for-non-x86-targets-using-qemu
How and why to make android self-hosting:
http://landley.net/aboriginal/about.html#selfhost
4) What's new with toybox (ELC 2015 status update):
video: http://elinux.org/ELC_2015_Presentations
outline: http://landley.net/talks/celf-2015.txt
--- Contributing
The three important URLs for communicating with the toybox project are:
web page: http://landley.net/toybox
mailing list: http://lists.landley.net/listinfo.cgi/toybox-landley.net
git repo: http://github.com/landley/toybox
The maintainer prefers patches be sent to the mailing list. If you use git,
the easy thing to do is:
git format-patch -1 $HASH
Then send a file attachment. The list holds messages from non-subscribers
for moderation, but I usually get to them in a day or two.
Although I do accept pull requests on github, I download the patches and
apply them with "git am" (which avoids gratuitous merge commits). Closing
the pull request is then the submitter's responsibility.
If I haven't responded to your patch after one week, feel free to remind
me of it.
Android's policy for toybox patches is that non-build patches should go
upstream first (into vanilla toybox, with discussion on the toybox mailing
list) and then be pulled into android's toybox repo from there. (They
generally resync on fridays). The exception is patches to their build scripts
(Android.mk and the checked-in generated/* files) which go directly to AOSP.
|
