(from v-1.2 ...)
Our first look, something well known:
Code:
core2quad arm-k1 $ cd bin
core2quad bin $ ls -l
total 612
-rwsr-sr-x 1 mszick mszick 620140 2008-03-30 19:14 busybox
It was brand new, eight years ago, approximately e-reader stone-age.
A quick summary:
Code:
core2quad bin $ file *
busybox: setuid setgid ELF 32-bit LSB executable, ARM, version 1, statically linked, for GNU/Linux 2.0.0, stripped
About what was expected, and it is at least little endian.
Try for a bit more detail:
Code:
core2quad bin $ readelf -a busybox | less
ELF Header:
Magic: 7f 45 4c 46 01 01 01 61 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: ARM
ABI Version: 0
Type: EXEC (Executable file)
Machine: ARM
Version: 0x1
Entry point address: 0x80d0
Start of program headers: 52 (bytes into file)
Start of section headers: 619540 (bytes into file)
Flags: 0x202, has entry point, GNU EABI, software FP
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 3
Size of section headers: 40 (bytes)
Number of section headers: 15
Section header string table index: 14
- - - -
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000000 0x00008000 0x00008000 0x94b64 0x94b64 R E 0x8000
LOAD 0x094b64 0x000a4b64 0x000a4b64 0x02840 0x2317c RW 0x8000
NOTE 0x0000a0 0x000080a0 0x000080a0 0x00020 0x00020 R 0x10
- - - -
Notes at offset 0x000000a0 with length 0x00000020:
Owner Data size Description
GNU 0x00000010 NT_GNU_ABI_TAG (ABI version tag)
OS: Linux, ABI: 2.0.0
Note: The load address and alignment (this happens to be configured the same as a 'bare metal' executable).
Other than that, a fairly common sort of (early) Linux file.
Let's see if it will talk to us:
Code:
core2quad bin $ ./busybox
BusyBox v1.01 (2008.03.31-00:04+0000) multi-call binary
Usage: busybox [function] [arguments]...
or: [function] [arguments]...
BusyBox is a multi-call binary that combines many common Unix
utilities into a single executable. Most people will create a
link to busybox for each function they wish to use and BusyBox
will act like whatever it was invoked as!
Currently defined functions:
[, addgroup, adduser, adjtimex, ash, awk, basename, bunzip2, busybox, bzcat, cat, chgrp, chmod, chown, chroot,
clear, cmp, cp, crond, crontab, cut, date, dd, delgroup, deluser, df, dirname, dmesg, du, echo, env, expr,
false, fdisk, fgrep, find, freeramdisk, getty, grep, gunzip, gzip, halt, head, hexdump, hostname, hwclock,
id, ifconfig, ifdown, ifup, init, install, ip, ipaddr, iplink, iproute, kill, killall, klogd, linuxrc, ln,
logger, login, logname, logread, losetup, ls, makedevs, md5sum, mkdir, mknod, mktemp, more, mount, mv, nc,
netstat, passwd, pidof, ping, pipe_progress, pivot_root, printf, pwd, rdate, readlink, realpath, reboot,
renice, reset, rm, rmdir, route, run-parts, sed, seq, sh, sleep, sort, start-stop-daemon, strings, stty,
su, sulogin, sync, sysctl, syslogd, tail, tar, tee, telnet, test, time, touch, tr, traceroute, true, tty,
udhcpc, umount, uname, uniq, uptime, usleep, vi, wc, wget, which, who, whoami, xargs, yes, zcat
core2quad bin $
Again, about what one would expect.
(For the curious reader, "core2quad" is the name of my development machine, an Intel x86_64, here running in 32-bit mode.
And yes, I didn't photoshop the above, my i686 Linux install does run ARM code just fine.
I couldn't do much here if it didn't.
)
= = = =
@geekmaster - first test - duplicate the above.
It is statically linked, it should run anywhere on the K1 that you put it.
copy /bin/busybox to ??? <wherever> you are trying to run your compiled code from (sd card, usb storage, whatever) -
then with that as the current working directory, do
./busybox
see if it will talk to you from that location on your K1.
I.E: We **know** this thing works, make sure it works for you also.
This first test is to eliminate any funky file system options that might be keeping your code from running properly (or at all).