On 9/23/2010 7:53 PM, Rene Rebe wrote:
Hi,
MIPS64 appears to be building much better now in trunk, with n64/o32 multilib.
You can likewise adapt the patches to just build either of those or o32 .
Have fun!
René
Sent abroad - http://ExactCODE.com Germany.
The Mips64 build is Working wonderfully now, once I get dietlibc & embedutils out of the
way, everything else builds right up to the kernel.
Patch attached to skip dietlibc & embedutils, so the rest will build (for those who cant
wait for the final dietlibc fix :-)
The kernel built successfully but failed on the Install.
===[main_lx:84 (last $?=0)> case "$lx_cpu" in
===[main_lx:98 (last $?=0)> cp -vf vmlinux.ecoff
/opt/T2/t2-trunk/build/Mips64-orig-9.0-trunk-generic-mips64-EB-cross-linux/boot/vmlinux_2.6.35.5-dist.ecoff
cp: cannot stat `vmlinux.ecoff': No such file or directory
Due to previous errors, no 1-linux26.log file!
(Try enabling xtrace in the config to track an error inside the build system.)
--- BUILD ERROR ---
This error is with the Generic T2 Mips64 kernel
I think that vmlinux.ecoff is something used by old DECstations, I never noticed it in my
Octeon specific kernels, but have not investigated this in depth yet. I am going to
switch to my own board specific kernel next, and see how it builds
BTW, I am building on a Suse SLES11 machine.
Thanks again Rene,
Jan
On Sep 23, 2010, at 21:19, Jan Rovins<[email protected]> wrote:
On 9/23/2010 2:39 PM, René Rebe wrote:
Hi,
On Sep 23, 2010, at 20:13 , Jan Rovins wrote:
On 9/23/2010 1:37 PM, Rene Rebe wrote:
Porting the MIPS bits in dietlibc to 64 bit may only take some hours of trial
and error. In fact I may even do so the next days (donations welcome :-).
I looked at that dietlibc code a while ago, and tried to do some things so it
would build for mips64, but I gave up because there was too much mips32
specific assembly code in there that would need porting, and my knowledge of
Mips64 assembly was not sufficient to do this in a reasonable amount of time,
If you can find a way to bypass those assembly code issues, or are not daunted
by coding at that level, perhaps a few hours will do it.
well, I'm doing such stuff for years.
You could mark dietlibc [R] - mips64 temporarily (in it's .desc).
Thanks for the tip.
I have a local mips64 glibc fix that i am just test build to check regressions
and hope to commit any minute.
The glibc solution is at the heart of the mips64 building troubles, I was never
able to get multilib working, so I bailed out into building it either as n64abi
or n32abi. for embedded purposes, it may still be good to let the user specify
whether its multilib, single lib n64 or single lib n32.
In building off the trunk as it is right now, I am getting the o32 abi libs in
/lib and the n32 abi libs in /lib64.
The question arises as to which libs really should be used where. The o32 abi
libs are the true old 32 bit libs which will allow the running of the ancient
mips32 binaries on a mips64 system, but the n32 abi libs are of more interest
to someone running on modern 64bit hardware, and wants to maintain a 32 bit
user space. the n32 abi relies on some 64bit hardware features, and is not
usable on 32bit hardware, but it is still a 32 bit abi, not a full 64bit abi. I
think n32 would be the most common choice for a 32bit abi on current Mips
technology. I think the true n64 abi should be in /lib64. The question is:
does one library solution make sense for every one using Mips64, or should we
let them pick their own combos?
Personally I would set it up like powerpc64, or x86-64, that is default to the
full 64bit binaries in lib64 and have fully backward compatible lib/ support to
support running the vanilla 32bit binaries of the architecture, which for MIPS
would mean o32.
Yes that makes sense in respect to keeping the /lib setup consistent across all
the different architectures supported by T2.
I see little benefit in supporting the n32 variant. Of course anyone is free to
setup his target to build n32 if they want to gain the extra performance %
digit, ... But as outlined I would default to reasonable choices, the efforts
to keep them working are already high enough. The Linux kconfig has this:
Select this option if you want to run n32 binaries. These are
64-bit binaries using 32-bit quantities for addressing and certain
data that would normally be 64-bit. They are used in special
cases.
If unsure, say N.
Even though the kernel says "Say No", I think n32 will be of high intrest to
embedded developers, working on new Mips64 hardware. Once you have the fundamental
multilib issues sorted out, I will submit an other patch to allow the use of n32 in some
way that makes sense, and hopefully won't involve too much effort to maintain.
Jan
So this would mean fixing trunk to built n64 binaries instead of n32 gcc is
apparently (accidentally) defaulting to.
René
Index: package/base/embutils/embutils.desc
===================================================================
--- package/base/embutils/embutils.desc (revision 37673)
+++ package/base/embutils/embutils.desc (working copy)
@@ -24,6 +24,7 @@
[M] Rene Rebe <[email protected]>
[F] CROSS DIETLIBC
+[R] -mips64
[C] base/system
Index: package/base/dietlibc/dietlibc.desc
===================================================================
--- package/base/dietlibc/dietlibc.desc (revision 37673)
+++ package/base/dietlibc/dietlibc.desc (working copy)
@@ -28,7 +28,7 @@
[E] group libc
[F] CROSS NOPARALLEL DIETLIBC LIBC NO-SSP
-[R] - avr32 blackfin cris m68k superh superh64
+[R] - avr32 blackfin cris m68k superh superh64 mips64
[L] GPL
[S] Stable
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[email protected] with a subject of: unsubscribe t2
