Unfortunately no one can be told what fun_plug is - you have to see it for yourself.
You are not logged in.
hello,
i am trying to build a cross-compile environment for the 313, and i've tried these options:
1) openwrt with sl2312 patch - everything compiles fine, but lot of packages for a NAS are missing (samba, ftp, etc..)
2) buildroot package - i'm unable to make it work. build scripts doesn't respect paths and build host types, and it fails on first package
3) uClibc - there is problem with a linux include headers. there is no way to create kernel include files to a userspace, and uClibc fails to include linux/sysctl.h
so, anyone knows how to build functional build environment? i'd like to have it, so i can start building my own system.
Offline
Hi, pcp,
in this thread http://dns323.kood.org/forum/t1356-HOWT … S-313.html
andrew reported, he has setting up cross compile environment.
I would prefer this way too, but need more hints...
But seems, andrew is no more active in this forum.
Last edited by CharminBaer (2008-05-12 17:29:29)
Offline
Yes, it works for me. The d-link's toolchain is a good starting point. But i'd like to build the cc environment from scratch. I want to use uClibc, because it is dedicated for embedded systems. And i want to have another programs linked against it.
Offline
uclibc works, but you should either use snapshot or apply the fix mentioned in here: http://bugs.busybox.net/view.php?id=3124
If you want to compile kernel sources from dlink there may be 3 syntax bugs in the source that prevent compiling, but they are quite simple to fix.
Otherwise uclibc works very good, if you need some help give me a message
Offline
look there...
http://buildroot.uclibc.org/buildroot.html
Iīm not tried yet, but it sounds interesting.
Offline
CharminBaer wrote:
look there...
http://buildroot.uclibc.org/buildroot.html
Iīm not tried yet, but it sounds interesting.
i've tried it, but it fails hardly for some weird reason. it compiles the packages with gcc, then attempts to link with arm-ld. and it removes and unpacks ALL packages every remake. awful system
naffarin, i've got following problem when i am compiling uClibc:
In file included from ./include/sys/sysctl.h:45,
from libc/sysdeps/linux/arm/ioperm.c:46:
/usr/include/linux/sysctl.h:34: warning: no semicolon at end of struct or union
in short, the uclibc include #undef some variables, which in turn are needed in kernel includes. I've found on google that's because use of the internal kernel includes instead of set of includes generated by a make make_headers. but this target isn't supported by d-link's kernel.
Offline
pcp wrote:
hello,
i am trying to build a cross-compile environment for the 313, and i've tried these options:
1) openwrt with sl2312 patch - everything compiles fine, but lot of packages for a NAS are missing (samba, ftp, etc..)
2) buildroot package - i'm unable to make it work. build scripts doesn't respect paths and build host types, and it fails on first package
3) uClibc - there is problem with a linux include headers. there is no way to create kernel include files to a userspace, and uClibc fails to include linux/sysctl.h
so, anyone knows how to build functional build environment? i'd like to have it, so i can start building my own system.
as far as i know, my ffp 0.5 runs on the 313, too. it includes a complete native toolchain (binutils 2.18, gcc 4.1, etc.) and is uClibc-based.
Offline
I rather think that was an error that is caused by using kernel header instead of sanitized headers...do you use the d-link toolchain for the linux includes ? If you do, you should switch to a suitable header package like linux-headers-2.6.12 in the buildroot config.
By the way for me buildroot is working fine (after a few , well , after a lot of experimenting with the config).
You shoudl go for the current buildroot tarball (but not the svn snapshot...i had some problems with that) and uclibc 0.9.29 with the above patch, that is a working combination for me.
Offline
Why not using the DNS-313 himself for make&compile? Too slow? Still donīt believe...
Today I installed gcc, make & co. at my box. But still get many errors and warnings.
Letīs see next week...
Offline
CharminBaer wrote:
Why not using the DNS-313 himself for make&compile? Too slow? Still donīt believe...
Today I installed gcc, make & co. at my box. But still get many errors and warnings.
Letīs see next week...
hi, i'm back
Generally, it isn't a good idea to compile on the embedded box - they usually have a slow cpu and a very little memory. Compiling the kernel this way would take more than one day, maybe longer.
If you want to use the d-links toolchain, you need to make sure you have the $CC, $PATH and other environment variables set'd up. The attached script can do this for you, just change the PATH= liine according to your d-link's source root.
When compiling the kernel, if you got the errors, try to do do $make clean first. It's not necessary to do it all the time, but if you are altering sources, there might be some unresolved dependencies.
Then you will need to add the bootp header. I'm using the original Makefile in the Image directory for that. Sadly, i dunno what I have changed in the past.
Things I remember I've changed
In the file
Image/toolchain/bin/mkflash
comment out the line rm -rf system_tmp.tgz
and in the Image/Makefile
make sure the script will copy the zImage to the Image/src/kernel (line 37)
this will create system_tmp.tgz, which includes all files you need: kernel, ramdisk, and a root filesystem
feel free to ask if you have errors..
cheers,pcp
Offline
and you need to be root for the final make, because the script must loopmount the ramdisk/rootfs
Offline
pcp wrote:
Generally, it isn't a good idea to compile on the embedded box - they usually have a slow cpu and a very little memory. Compiling the kernel this way would take more than one day, maybe longer.
DNS-323 and DNS-313 are fast enough to compile most packages within reasonable time. The kernel is special in that it doesn't require a full cross-toolchain, so it's usually simple enough to cross-compile.
Offline
Hi, pcp,
welcome back again! It is nevertheless a good idea to compile with the box himself! I installed gcc and related tools and meanwhile had enough time to get experiences. Wrote a little prog for controlling fan, based on your g751-stuff. ( works as daemon, gets temperature values from commandline ) Compile time: a few seconds! Changed your pbutton-tool for running as daemon too, compiling is fast enough. But my ventures with buildroot I stopped after more than 30 hrs compile time! Really better to do such things on a ordinary PC.
But Iīm wondering, how can you use the DLink-toolchain on the box? The arm920t-le-toolchain is an i386-binary!? I took some experiments with the DLink-GPL-sources and the gcc on the box, but had not succeedet yet. But this is not essential, for these tasks I have several Linux-PCs at disposal.
So long, the Bear.
Offline
fonz wrote:
pcp wrote:
Generally, it isn't a good idea to compile on the embedded box - they usually have a slow cpu and a very little memory. Compiling the kernel this way would take more than one day, maybe longer.
DNS-323 and DNS-313 are fast enough to compile most packages within reasonable time. The kernel is special in that it doesn't require a full cross-toolchain, so it's usually simple enough to cross-compile.
I meant ordinary packages like libraries etc.I can't imagine compiling the large package like libc in reasonable amount of time, especially when you are developing stuff. For the simple programs like a fan control, it's still usable though.
Hope the folks from the openwrt project will make a release of a buildroot for the 313 SoC soon, their build system would be a great boon for everyone.
Offline
pcp wrote:
I meant ordinary packages like libraries etc.
Of course, ffp 0.5 is about 80 packages - all compiled natively on my dns-323. The "pain" of native compilation wasn't even big enough for me to install distcc or ccache.
Offline