SliTaz Forum
You are not logged in.
But I think eglibc is installed in /cross/arm/sysroot.
How do I "use" the glibc-base package in this way? (How do I tell arm-setup
install
file:///usr/share/doc/tazpkg/tazpkg.en.html
specify the root system where you want to install the packages via the --root= option:
# tazpkg install path/to/package-1.0.tazpkg --root=/mnt/rootfs
Offline
Checking build dependencies...
Using packages DB: /cross/arm/sysroot/var/lib/tazpkg
Installing dep (pkg/local): libxml2-dev-2.8.0-arm.tazpkg
Connecting to mirror.slitaz.org (46.105.127.17:80)
zlib-1.2.8.tazpkg 100% |*******************************| 35924 0:00:00 ETA
Connecting to mirror.slitaz.org (46.105.127.17:80)
glibc-base-2.14.1.ta 100% |*******************************| 1270k 0:00:00 ETA
Installing dep (pkg/local): libxml2-2.8.0-arm.tazpkg
setup-mirror|-sm Change the mirror url configuration.
# tazpkg setup-mirror (IN chroot)
http://cook.slitaz.org/cross/arm/packages/
Or path/to/your_arm_packages
Offline
Thanks! Downloading and installing glibc-base with [c]tazpkg --root=[/c] fixed my chrooted system. Although its still removes glibc-base every time I cook anything (successfully or not). This is even with a package that should normally work (and without any downloads from the mirror).
[c]
Cook: ncurses 5.9
================================================================================
arm sysroot: /cross/arm/sysroot
Adding /cross/arm/tools/bin to PATH
Using cross-tools: arm-slitaz-linux-gnueabi-
QA: checking package receipt...
Using packages DB: /cross/arm/sysroot/var/lib/tazpkg
Connecting to invisible-island.net (216.194.248.64:21)
ncurses-5.9.tar.gz 100% |*******************************| 2760k 0:00:00 ETA
Extracting: ncurses-5.9.tar.gz
Executing: compile_rules
CFLAGS : -march=armv6 -O2
Installing: ncursesw-extra
configure: loading site script /etc/slitaz/cook.site
checking for egrep... grep -E
Configuring NCURSES 5.9 ABI 5 (Sat Mar 1 04:24:22 UTC 2014)
checking build system type... i486-slitaz-linux-gnu
checking host system type... arm-slitaz-linux-gnueabi
checking target system type... arm-slitaz-linux-gnueabi
Configuring for linux-gnueabi
checking for prefix... /usr
checking for arm-slitaz-linux-gnueabi-gcc... arm-slitaz-linux-gnueabi-gcc
checking for C compiler default output... configure: error: C compiler cann
eate executables
Build dependencies to remove: 6
Removing: glibc-base/usr/bin/tazpkg: line 139: dirname: not found
/usr/bin/tazpkg: line 139: dirname: not found
[/c]
In the meantime, I've been trying to get native compilation to work. I got gcc to work with [c]qemu-arm-static[/c] by side-stepping the issue and using [c]tazpkg convert[/c] from Debian wheezy packages.
https://github.com/pirandr/slitaz-arm/tree/master/wheezy-conversion
Although it would need quite a bit more before I can start building things with it (and even more if we want to use [c]cook[/c] to get tazpkg out of the things built this way).
Offline
You know, this is one reason I want to make a Buildroot built flavour of SliTaz since cross-arch versions is just a rebuild away.
Offline
Chrooted build environment
For the moment, I've just commented out the call to [c]remove_deps[/c] in [c]cook[/c], which probably doesn't make distributable packages but at least makes it much less annoying while I'm trying things.
libxslt
I've managed to cook libxslt, by accident. At first I was also getting the error message
[c]
/usr/lib/libxml2.so: could not read symbols: File in wrong format
[/c]
But then I moved /usr/lib/libxml2.so on the host (to something like /usr/lib/libxml2.so.old) and it cooked. Although there were some errors when it tried to download DTDs for xhtml, the package seems to have built.
The packages built:
https://github.com/pirandr/slitaz-arm/tree/master/cross-compiled
The DTD errors:
[c]
Validating the HTML Web pages
I/O error : Attempt to load network entity http://www.w3.org/TR/xhtml1/DTD/xhtml
API.html:2: warning: failed to load external entity "http://www.w3.org/TR/xhtml1
1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"
^
API.html:3: validity error : Validation failed: no DTD found !
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type"
^
I/O error : Attempt to load network entity http://www.w3.org/TR/xhtml1/DTD/xhtml
bugs.html:2: warning: failed to load external entity "http://www.w3.org/TR/xhtml
1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"
^
bugs.html:3: validity error : Validation failed: no DTD found !
[/c]
I think the network just timed out. I was able to download those files later but the server took some time to respond.
python
It seems there are many superfluous dependencies for python. They are needed for for building certain modules but since python is sometimes a build dependency for other things that don't need those modules, might I suggest that python be split this into two separate packages: one minimal one called "python" without the deps and another called "python-full" (with the extra deps) or something like that?
This is especially true now that C might not be needed while cross compiling for a host system some something like gdbm (which depends on gcc) is no longer needed as a dependency.
I feel like the minimal version would have almost no dependencies.
Here's an untested receipt. Its rather meant to describe how I cross-compiled python than a receipt proper (maybe someone more knowledgeable can make a real one). The problem is that the first part needs to be built on the host (since that binary will run to build the second part). Or maybe python itself can be a build dep but I don't know if the binary Parser/pgen (which is also needed to build python) is installed usually.
https://github.com/pirandr/slitaz-arm/blob/master/cross-compiled/python-2.7.5-receipt
I also managed to make a native build through qemu-arm-static without any trouble (no patches needed).
The extra modules that would be missing are
_sqlite3 _tkinter bsddb185
gdbm sunaudiodev
And now that I finished building it, I forgot what depends on it...
Buildroot
@Trixar_za: What is this sorcery? I'll have to try using buildroot later. At least if it can really combine the things it claims to be able to in menuconfig, I'm really impressed. For a distro-less build with rarely changing programs, this is perfect! (Rarely changing or all changes have to happen on a different machine anyway.)
A Slitaz flavour would certainly be welcome.
Offline
My plan is to include the SliTaz scripts as a custom Buildroot package so it'll be a selectable option within Buildroot menuconfig. That should also simplify the process for building SliTaz distros with Buildroot.
I also want to create a bash script based on tazpkg so I can package build Buildroot packages into something SliTaz can use.
Well, that's the plan. But like you know, most plans don't work out as easily as planned. Buildroot still requires some knowledge of how to build a Linux distro from scratch even if it simplifies the building part.
Offline
buildroot
Both would have been extremely helpful here! Although my first attempt to use buildroot ended up in a compilation error (for some read the version of [c]ld[/c] it generated for the host had some "unresolved name" or something. It also doesn't seem to be compatible with SliTaz's tar for the moment). I'll have to try again (much?) later.
But like you know, most plans don't work out as easily as planned.
"All I need is X. Someone already managed to build X at some point. Yeah, this will be quick." (And now we are 3 weeks later.)
libtool minefield
I managed to build some more dependencies for xorg-server
https://github.com/pirandr/slitaz-arm/tree/master/cross-compiled
but along the way, I met many problems similar to the one for libxml2 (where I just moved the host library away). Of course, this stops working after a while when the shared library is needed by a binary on the host is called during compilation.
This lead me to
http://www.metastatic.org/text/libtool.html
which describes my problem accuratedly. I'm a bit more chicken so I used this [c]sed[/c] script instead
https://github.com/pirandr/slitaz-arm/blob/master/cross-compiled/libtool-minefield
Of course, the right thing to do is probably to change these *.la files post-compilation in the receipt somewhere. Although, this means a native build might fail then...
Build dependencies
While building those packages, I noticed one thing: there's ambiguity in a receipt's BUILD_DEPENDS. Sometimes, it means a host dependency (like [c]autoconf[/c] and [c]automake[/c]) and sometimes, it means a target dependency (like some header files).
These two types of dependencies should probably be distinguished at some point.
Offline
My initial struggle with it was getting it to compile without linux kernel build errors - I was doing an 32 bit build on a 64 bit server. The trick was to name the kernel's location 'i386' rather than slitaz like I wanted.
You also need to go through a 'make linux-menuconfig' and 'make busybox-menuconfig' stages to get all the selectable options. Building also takes some time. Up to an hour for me - so I detach from the session and come back to it when I'm done. It helps to output to a file when you do that so you can just tail it for any errors.
Offline
https://github.com/pirandr/slitaz-arm
1. slitaz-arm-toolchain-20140228.tar.bz2
https://github.com/pirandr/slitaz-arm/blob/master/slitaz-arm-toolchain-20140228.tar.bz2
root 2 days ago Initial
0 contributors
file 85363.318 kb
2.
root@slitaz:/# /tmp/libc-2.13.so
GNU C Library (EGLIBC) stable release version 2.13, by Roland McGrath et al.
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.6.3.
Compiled on a Linux 3.2.14 system on 2014-02-28.
Available extensions:
crypt add-on version 2.1 by Michael Glad and others
GNU Libidn by Simon Josefsson
Native POSIX Threads Library by Ulrich Drepper et al
Support for some architectures added on, not maintained in glibc core.
BIND-8.2.3-T5B
libc ABIs: UNIQUE
For bug reporting instructions, please see:
<http://www.eglibc.org/issues/>.
3.
root@slitaz:~# file /cross/arm/sysroot/lib/libc-2.13.so
/cross/arm/sysroot/lib/libc-2.13.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, not stripped
4. Compiler executable checksum: cde56a52bb4f2dbe8ce593dcc61b0f63
root@slitaz:~# echo 'int main() { return 0; }' > test.c
root@slitaz:~# arm-slitaz-linux-gnueabi-gcc -v -o test-0302 test.c
Using built-in specs.COLLECT_GCC=arm-slitaz-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/cross/arm/tools/lib/gcc/arm-slitaz-linux-gnueabi/4.6.3/lto-wrapper
Target: arm-slitaz-linux-gnueabi
Configured with: ../gcc-4.6.3/configure --prefix=/cross/arm/tools --libexec=/cross/arm/tools/lib --target=arm-slitaz-linux-gnueabi --enable-shared --enable-c99 --enable-long-long --enable-__cxa_atexit --with-system-zlib --enable-plugin --disable-multilib --disable-libssp --disable-checking --disable-werror --with-pkgversion=SliTaz --with-bugurl=https://bugs.slitaz.org/ --with-sysroot=/cross/arm/sysroot --enable-languages=c,c++
Thread model: posix
gcc version 4.6.3 (SliTaz)
COLLECT_GCC_OPTIONS='-v' '-o' 'test-0302'
/cross/arm/tools/lib/gcc/arm-slitaz-linux-gnueabi/4.6.3/cc1 -quiet -v test.c -quiet -dumpbase test.c -auxbase test -version -o /tmp/ccCh87O3.s
GNU C (SliTaz) version 4.6.3 (arm-slitaz-linux-gnueabi)
compiled by GNU C version 4.6.3, GMP version 5.0.4, MPFR version 3.1.0-p4, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=65536
ignoring nonexistent directory "/cross/arm/sysroot/usr/local/include"
#include "..." search starts here:
#include <...> search starts here:
/cross/arm/tools/lib/gcc/arm-slitaz-linux-gnueabi/4.6.3/include
/cross/arm/tools/lib/gcc/arm-slitaz-linux-gnueabi/4.6.3/include-fixed
/cross/arm/tools/lib/gcc/arm-slitaz-linux-gnueabi/4.6.3/../../../../arm-slitaz-linux-gnueabi/include
/cross/arm/sysroot/usr/include
End of search list.
GNU C (SliTaz) version 4.6.3 (arm-slitaz-linux-gnueabi)
compiled by GNU C version 4.6.3, GMP version 5.0.4, MPFR version 3.1.0-p4, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=65536
Compiler executable checksum: cde56a52bb4f2dbe8ce593dcc61b0f63
COLLECT_GCC_OPTIONS='-v' '-o' 'test-0302'
/cross/arm/tools/lib/gcc/arm-slitaz-linux-gnueabi/4.6.3/../../../../arm-slitaz-linux-gnueabi/bin/as -meabi=5 -o /tmp/ccqIAVNV.o /tmp/ccCh87O3.s
COMPILER_PATH=/cross/arm/tools/lib/gcc/arm-slitaz-linux-gnueabi/4.6.3/:/cross/arm/tools/lib/gcc/arm-slitaz-linux-gnueabi/4.6.3/:/cross/arm/tools/lib/gcc/arm-slitaz-linux-gnueabi/:/cross/arm/tools/lib/gcc/arm-slitaz-linux-gnueabi/4.6.3/:/cross/arm/tools/lib/gcc/arm-slitaz-linux-gnueabi/:/cross/arm/tools/lib/gcc/arm-slitaz-linux-gnueabi/4.6.3/../../../../arm-slitaz-linux-gnueabi/bin/
LIBRARY_PATH=/cross/arm/tools/lib/gcc/arm-slitaz-linux-gnueabi/4.6.3/:/cross/arm/tools/lib/gcc/arm-slitaz-linux-gnueabi/4.6.3/../../../../arm-slitaz-linux-gnueabi/lib/:/cross/arm/sysroot/lib/:/cross/arm/sysroot/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-o' 'test-0302'
/cross/arm/tools/lib/gcc/arm-slitaz-linux-gnueabi/4.6.3/collect2 --sysroot=/cross/arm/sysroot --eh-frame-hdr -dynamic-linker /lib/ld-linux.so.3 -X -m armelf_linux_eabi -o test-0302 /cross/arm/sysroot/usr/lib/crt1.o /cross/arm/sysroot/usr/lib/crti.o /cross/arm/tools/lib/gcc/arm-slitaz-linux-gnueabi/4.6.3/crtbegin.o -L/cross/arm/tools/lib/gcc/arm-slitaz-linux-gnueabi/4.6.3 -L/cross/arm/tools/lib/gcc/arm-slitaz-linux-gnueabi/4.6.3/../../../../arm-slitaz-linux-gnueabi/lib -L/cross/arm/sysroot/lib -L/cross/arm/sysroot/usr/lib /tmp/ccqIAVNV.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /cross/arm/tools/lib/gcc/arm-slitaz-linux-gnueabi/4.6.3/crtend.o /cross/arm/sysroot/usr/lib/crtn.o
5.
root@slitaz:~# readelf -A test-0302
Attribute Section: aeabi
File Attributes
Tag_CPU_name: "6"
Tag_CPU_arch: v6
Tag_ARM_ISA_use: Yes
Tag_THUMB_ISA_use: Thumb-1
Tag_ABI_PCS_wchar_t: 4
Tag_ABI_FP_denormal: Needed
Tag_ABI_FP_exceptions: Needed
Tag_ABI_FP_number_model: IEEE 754
Tag_ABI_align_needed: 8-byte
Tag_ABI_align_preserved: 8-byte, except leaf SP
Tag_ABI_enum_size: int
Tag_DIV_use: Not allowed
root@slitaz:~#
Offline
https://github.com/pirandr/slitaz-arm/blob/master/slitaz-arm-toolchain-20140228.tar.bz2
file 85363.318 kb
/cross/arm/sysroot/lib/libc-2.13.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, not stripped
1. clean-tools Clean: /cross/arm/tools
# cross --help
Usage: cross command --option
Commands:
howto Man[like] page and howto
info Display cross-tools info
testsuite Execute a small testsuite
check Check build host environment
download Download necessary sources
show-log Show a compile log
binutils Compile Binutils
linux-headers Install Kernel headers
gcc-static Compile GCC static
glibc Compile GNU Glibc
gcc-final Compile final GCC
compile Compile everything at once
clean Clean-up build environment
clean-tools Clean: /cross/arm/tools
gen-prebuilt Create a prebuilt toolchain archive
clean-tools)
# Remove crap :-)
2. README
Move this arm cross compilation toolchain to /usr/cross then add tools
to your PATH environment and test the toolchain:
# mv arm /cross
/usr/cross
should be /cross
Offline
directfb
Looks like someone added directfb to arm. I tried it on the actual board but sadly, [c]dfbterm[/c] didn't work. At least not right away (see attached). I have no prior experience with [c]directfb[/c] so it could be that I'm not setting something up right.
Some of the directfb-examples did work though like [c]df_input[/c] and [c]df_mouse[/c]. [c]df_fire[/c] worked but didn't display anything that looked like fire. I suspect there's a problem with the palette (but the problem is consistent since the fonts rendered in [c]df_input[/c] and [c]df_mouse[/c] were perfectly readable).
buildroot
Oh, my [c]buildroot[/c] hadn't gotten to building a kernel yet. It's stuck on host-gcc-initial after installing
ccache binutils m4 gmp mpfr mpc mpc
on the host.
Cross compilation tools (as of 20140228)
Thanks for trying this out! I'll have to look into it later.
Offline
>So that's why I tried to move from Raspbian to SliTaz.
Have any idea?
I'm not sure what you mean. Do you mean
We missed a good chance on Raspberry Pi.
Maybe we can do better.
*** Not tested, many bugs … ***
packages-armhf-620.list
http://goo.gl/jlXx89
packages-arm-334.list
http://goo.gl/T1zzqC
wok-arm-353.tar.xz
http://goo.gl/4zwlDm
packages-arm-334.tar.xz
http://goo.gl/y8sZqJ
packages-armhf-620.tar.bz2
http://goo.gl/GekuBU
Offline
*** Not tested, many bugs … ***
packages-armhf-620.list
http://goo.gl/jlXx89
packages-arm-334.list
http://goo.gl/T1zzqC
wok-arm-353.tar.xz
http://goo.gl/4zwlDm
packages-arm-334.tar.xz
http://goo.gl/y8sZqJ
packages-armhf-620.tar.bz2
http://goo.gl/GekuBU
Oh, wow, thanks! I didn't know you already had so much built. Even if it is buggy, having somewhere to start is really helpful.
My initial try with [c]X -nolisten tcp[/c] froze the Pi immediately, but I'll look at your receipts and try different variations for the build.
We missed a good chance on Raspberry Pi.
Maybe we can do better.
Ah, you mean to popularize SliTaz? Maybe. But as you said, let's see what comes out of this. I think the Raspberry Pi's popularity might make more ARM SoC available so the work here wouldn't really be lost unless the custom hardware is really different.
The Raspberry is a bit weird anyway with its proprietary GPU and bootcode on that proprietary GPU.
Offline
make more ARM SoC available so the work here wouldn't really be lost unless the custom hardware is really different.
even if the custom hardware is really different
boot section: bootloader,kernel (custom)
rootfs: almost the same
Offline
Cortex-A8
1. MK802 II
Main Chip: Allwinner A10/ 1GHz Cortex-A8
Memory: 1GB
Storage: 4GB
GPU: Mali400
Expansion: Micro SD 2-32GB Memory
2. custom kernel
tc@box:~$ uname -a
Linux box 3.0.42-slitaz #1 PREEMPT Tue Oct 9 19:22:19 UTC 2012 armv7l GNU/Linux
3. Machine: sun4i and Sourcery toolchain
tc@box:~$ dmesg | head -5
[ 0.000000] Initializing cgroup subsys cpuset
[ 0.000000] Linux version 3.0.42-slitaz (root@slitaz) (gcc version 4.5.1 (Sourcery G++ Lite 2010.09-50) ) #1 PREEMPT Tue Oct 9 19:22:19 UTC 2012
[ 0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d
[ 0.000000] CPU: VIPT nonaliasing data cache, VIPT aliasing instruction cache
[ 0.000000] Machine: sun4i
http://goo.gl/hjt9gH
4. Tiny Core on mk802
http://forum.tinycorelinux.net/index.php/topic,14476.0.html
« on: November 28, 2012, 03:11:25 PM »
I see someone has Tiny Core on the tiny mk802.
http://alanyih.blogspot.com/2012/10/mk802-tinycore.html
Offline
The Raspberry is a bit weird anyway with its proprietary GPU and bootcode on that proprietary GPU.
Android for All: Broadcom Gives Developers Keys to the VideoCore® Kingdom
Posted: Feb. 28, 2014
http://blog.broadcom.com/chip-design/android-for-all-broadcom-gives-developers-keys-to-the-videocore-kingdom/
Today, Broadcom is releasing the full source of the OpenGL ES 1.1 and 2.0 driver stack for the Broadcom VideoCore® IV 3D graphics subsystem used in the BCM21553 3G integrated baseband SoC. VideoCore IV is used in many Broadcom products, including the BCM2835 application processor, which runs the popular Raspberry Pi microcomputer.
Download BCM21553 GPU Documentation
http://www.broadcom.com/docs/support/videocore/VideoCoreIV-AG100-R.pdf
Download BCM21553 Graphics Driver
http://www.broadcom.com/docs/support/videocore/Brcm_Android_ICS_Graphics_Stack.tar.gz
Related Story
Happy Birthday, Raspberry Pi! More Than 2.5M and Counting
http://blog.broadcom.com/raspberry-pi/happy-birthday-raspberry-pi-more-than-2-5m-and-counting/
A birthday present from Broadcom
http://www.raspberrypi.org/archives/6299
Offline
libtool minefield
This lead me to
http://www.metastatic.org/text/libtool.html
which describes my problem accuratedly. I'm a bit more chicken so I used this sed script instead
https://github.com/pirandr/slitaz-arm/blob/master/cross-compiled/libtool-minefield
1. http://forum.slitaz.org/topic/chroot#post-18810
Avoiding libtool minefields when cross-compiling
http://www.metastatic.org/text/libtool.html
2. Cross Toolchain
http://cook.slitaz.org/cross/arm/toolchain.cgi
Packages log: binutils eglibc gcc-final gcc-static libtool linux-headers
Offline
About libtool: latest cook/cross use the sed hack to fix libs path and I also added 'cross libtool'. With the last cookutils from Hg cross compiltion on Slitaz is getting easier!
I'will also soon announce the new SliTaz ARM website: http://arm.slitaz.org
Offline
@pankso, Thanks.
OMG!
Welcome to SliTaz ARM
http://arm.slitaz.org
This website provides information, notes and links about the SliTaz GNU/Linux port to the ARM architecture. SliTaz currently support the ARM v6 (armel) architecture and work is on the stove for armv6hf (hard float).
[..]
Raspberry Pi
Currently the SliTaz official ARM port works on the Raspberry Pi and can be used to setup a small server. DirectFB is ported and provides a nice and light GUI support. A new tool is also on the stove to create custom Rpi flavors with an official Kernel, custom boot options and more.
[..]
Prebuilt ARM Toolchain
slitaz-arm-toolchain-20120519.tar.bz2
slitaz-arm-toolchain-20140222.tar.bz2
slitaz-arm-toolchain-20140304.tar.bz2
[..]
cross: add support for armv6hf and armv7 arch + better setup command
http://hg.slitaz.org/cookutils/rev/af5a93d961f0
files Makefile cross cross.conf data/cross-arm.conf data/cross-armv6hf.conf data/cross-armv7.conf data/cross-x86_64.conf doc/cross.txt
Packages: 182 in the wok - 181 cooked - 1 unbuilt - Server date: 2014-03-07 15:21 CET
....
Offline
QEMU patches for Raspberry Pi emulation
https://github.com/Torlus/qemu-rpi
About
================================================================================
This project aims at providing a basic chipset emulation of the Raspberry Pi,
to help low-level programmers or operating system developers in their tasks.
[..]
Emulated chipset parts are at the time of this writing:
- System Timer.
- UART.
- Mailbox system.
- Framebuffer interface.
- DMA.
- eMMC SD host controller.
The emulation is quite incomplete for many parts, however it is advanced enough to boot a Pi-targetted Linux kernel, along with a SD image of a compatible Linux distribution.
[attachment=28330,1344]
Offline
@alaniyh
Fix README and clean-tools
I've finally got around to doing this and put up a new version at
https://github.com/pirandr/slitaz-arm
Although I think the version at http://mirror.slitaz.org/arm/cross/slitaz-arm-toolchain-20140304.tar.bz2 is already stripped. So its better not to update to my "new" version.
@pankso: The top of the README in slitaz-arm-toolchain-20140304.tar.bz2 is still wrong though as alanyih pointed out
/usr/cross
should be /cross
But actually, right now this README is hard coded into [c]cross[/c] and should probably also be updated (eventually).
Broadcom VideoCore
This sounds really good! (I'll have to look at the details to make sure this isn't another shim. 
) And what odd timing too. It also seems like its not just for the Raspberry but possibly for other Broadcom boards.
The source release targets the BCM21553 cellphone chip, but it should be reasonably straightforward to port this to the BCM2835
I'm curious as to why they didn't release the source for BCM2835 alongside. It feels a bit strange, like this had nothing to do with the RaspPi at all (but happens to benefit it).
libtools minefield
Oops. I guess you figured it out a year earlier. Even with exactly the same link.
arm.slitaz.org
The page looks really cool and its nice to have everything gathered up in one place. (I'll have to try directfb again when I have time, which seems like never right now.)
xorg-server-light
Right. I should have tried getting the light version working first.
Currently, http://cook.slitaz.org/cross/arm/cooker.cgi?pkg=xorg-server-light shows a C compiler error, but this is a red herring.
I think the real problem is that some of the C libraries got replaced when dependencies were installed. I got the same error when I tried to cook [c]xorg-server-light[/c] on a fresh chroot.
I also realised that switching mirrors ([c]tazpkg -sm[/c]) is really dangerous when you have packages in the local cache (since it will pull from the cache, which came from another mirror). So you might end up installing things you didn't want to into /cross/arm/sysroot.
This can be fixed (temporarily) by just regenerating a [c]/cross/arm/sysroot[/c]. I just untarred the toolchain are replaced all of [c]/cross[/c].
However, this will keep happening (and replace some important files in [c]/cross/arm/sysroot[/c]). It turns out it is because it is trying to install [c]glibc-dev[/c] (which we don't have for arm yet) into [c]/cross/arm/sysroot[/c]. But I don't think this is actually needed.
Changing this let me get to the first real compilation error, which is a library path problem (about finding [c]pixman.h[/c]). And that's where I stopped.
Offline
I also realised that switching mirrors (tazpkg -sm) is really dangerous when you have packages in the local cache (since it will pull from the cache, which came from another mirror).
Sorry!
1.Using packages DB: /cross/arm/sysroot/var/lib/tazpkg
http://forum.slitaz.org/topic/slitaz-on-armel/page/2#post-28162
vi /cross/arm/sysroot/var/lib/tazpkg/mirror <====
http://cook.slitaz.org/cross/arm/packages/
Or path/to/your_arm_packages
2. add libtool
libtools minefield
Oops. I guess you figured it out a year earlier. Even with exactly the same link.
add libtool
2. Cross Toolchain
http://cook.slitaz.org/cross/arm/toolchain.cgi
Packages log: binutils eglibc gcc-final gcc-static libtool linux-headers
Offline
I just wanted to drop a quick note.
xorg-server-light
I just cooked [c]xorg-server-light[/c], but used a few hacks for now. I haven't tested it yet on the Pi.
https://github.com/pirandr/slitaz-arm/blob/master/cross-compiled/xorg-server-light-1.12.4-arm.tazpkg
The main problem (aside from the [c]glibc-dev[/c] issue) was that it look for libraries in [c]/usr/lib[/c] instead of [c]/cross/arm/sysroot/usr/lib[/c]. For the hack I ran [c]sed[/c] against all generated [c]Makefile[/c]s, which I strongly advise against doing in a final solution.
Some possibilities are to explicitly pass the path to [c]configure[/c] for these libraries (I think there are only 2 or 3 in the end). Or maybe even make a custom [c]pkg-config[/c] for cross compilation (since configure calls [c]pkg-config[/c] to get these paths).
In the receipt I had, there was a typo setting up [c]ARM_LIBS[/c] but also these extra lines (I think which were added for ARM)
[c]<br />
XSERVERCFLAGS_LIBS="-L${ARM_LIBS} -lrt -lpthread -lgcrypt -lm -lz \<br />
-lcrypto -lpixman -lxkbfile -lXfont -lfreetype -lXau -lfontenc -lXdmcp" \<br />
XSERVERLIBS_LIBS="-L${ARM_LIBS} -lrt -lpthread -lgcrypt -lm -lz \<br />
-lcrypto -lpixman -lxkbfile -lXfont -lfreetype -lXau -lfontenc -lXdmcp" \<br />[/c]
which ended up doing more harm than good (I already removed [c]-lmd[/c] here). If they were only added to help with the arm build, maybe just keeping [c]-L${ARM_LIBS}[/c] in each case will be enough (haven't tested this yet either).
Cross compilation libtool
Thanks! I've add [c]libtool[/c] to [c]cross[/c] now.
Setting mirror
No problem. It didn't really cause much trouble. I'll try that way next.
Offline
Cross compilation libtool
Thanks! I've add libtool to cross now.
Build time : 7094s ~ 118m
How long Build time?
slitaz-arm-toolchain-20140310.tar.bz2
https://github.com/pirandr/slitaz-arm/blob/master/slitaz-arm-toolchain-20140310.tar.bz2
file 49745.431 kb
slitaz-arm-toolchain-20140311.tar.bz2
https://github.com/pirandr/slitaz-arm/blob/master/slitaz-arm-toolchain-20140311.tar.bz2
file 50066.873 kb
Summary - arm
Packages: 275 in the wok - 267 cooked - 8 unbuilt - Server date: 2014-03-13 13:51 CET
Offline
RasppberryPi
SoC: Broadcom BCM2835 (CPU + GPU. SDRAM is a separate chip stacked on top)
CPU: 700 MHz ARM11 ARM1176JZF-S core
GPU: Broadcom VideoCore IV,OpenGL ES 2.0,OpenVG 1080p30 H.264 high-profile encode/decode
Memory (SDRAM):256 MB / 512 MB
MK802 II
Main Chip: Allwinner A10/ 1GHz Cortex-A8
Memory: 1GB
Storage: 4GB, Micro SD 2-32GB Memory
GPU: Mali400
Radxa Rock
SOC Rockchip RK3188
CPU ARM Cortex-A9 quad core @ 1.6Ghz
Memory 1GB / 2GB DDR3 @ 800Mhz
Storage 4GB / 8GB NAND Flash, Micro-SD SDXC up to 128GB
GPU Mali400-mp4@533Mhz, OpenGL ES 2.0
Comparison of current ARM cores
http://en.wikipedia.org/wiki/Comparison_of_current_ARM_cores
[attachment=28384,1347] [attachment=28384,1348] [attachment=28384,1349]
Offline
[ Generated in 0.018 seconds, 7 queries executed - Memory usage: 1.64 MiB (Peak: 1.77 MiB) ]