Question regarding compiling a toolchain for a Broadcom SB1
Hi, I am trying to compile a toolchain for a Broadcom SB1 processor in big-endian mode with a host Operating System of Linux. (The SB1 is a MIPS64, but there is also a specific SB1 target.) So far, I'm running into error after error when attempting to build either directly on the board or attempting to build a cross-compiler (with a host of a Pentium 4 also running Linux). I've run through the various FAQs, HOWTOs and automated scripts, but they either don't do the combination I want or they won't work with the combination I want. A query on the MIPS mailing list produced a depressing result - one reply, saying they weren't sure it could even be done. The various Linux distros for MIPS architectures were not a whole lot better - the most recent were 32-bit and even those weren't that recent. The newest MIPS64 binary of GCC I could find was back in the 2.95 era. My question is simple enough - has anyone built a toolchain for a MIPS64-Linux-GNU target? I noticed someone posting recently that they'd conquered this problem for MIPS64 under the IRIX OS, so I'm guessing it must be possible under Linux. I would prefer a recipe to build the toolchain myself from source, but if you happen to know of a site with binaries for the SB1 under Linux, I wouldn't be horribly opposed. Jonathan Day __ Click here to donate to the Hurricane Katrina relief effort. http://store.yahoo.com/redcross-donate3/
Re: Question regarding compiling a toolchain for a Broadcom SB1
I don't have a mips64 version of glibc, I'm having to build the entire toolchain from the ground up. (Yuck.) I'm trying to build the entire toolchain as 64-bit native, which is adding to my problems. (Crosstool, for example, only supports 32-bit MIPS - and even then the build matrix is a pretty shade of red for the most part.) I tried building GCC 4.0.1, glibc 2.3.5 and binutils 2.16.1 as per the Linux-MIPS guide. GCC built to the bootstrap version, which I then installed. The compiler could not then be used to compile anything, though - crt1.o and crti.o were missing in action. I repeated the procedure using the versions of GCC, glibc and binutils in CVS. I get the same error. Again, if someone has these files for a recent toolchain for the SB1-Linux-Gnu target, I'd truly appreciate a copy as that may be sufficient to make some real progress. Now, although I do not have 64-bit tools for MIPS, I do have 32-bit tools. So, as a backup plan I tried to build a cross-compiling 64-bit toolchain for the MIPS box - my plan being to then compile a "native" 64-bit toolchain with the cross-compiler, so I could then kick the 32-bit tools off the system entirely. Binutils is protesting this plan, complaining that some of the object files are in the wrong format. (I'll post actual error messages when I go into work in about 6 hours.) The bad news is that this might be a valid complaint. One of the reasons I want to eliminate the old toolchain completely is that a number of programs (such as OpenMPI) have complained that the assembler is producing buggy code. I'm hoping it is good enough to compile a replacement, but it might not be. If it isn't, then I will definitely need the cross-compiler hosted on the Intel Linux box -OR- known good MIPS64 binaries. Now we get to the other problem. Binaries. Broadcom's binaries are 32-bit and compiled against a Red Hat 7.2 distribution. The distribution might not matter - it depends on what is assumed from that environment and what external libraries were used. The 32-bits part is a bigger problem, unless I can use it to generate a proper 64-bit toolchain. It looks like it is also only a bootstrap compiler, as they say on their SiByte webpage that it won't compile Linux applications and is only good for firmware development. There's also a Debian MIPS distribution. Also 32-bit. Probably a little more complete than a firmware compiler and definitely one of the better options. MIPS.com has a toolchain. For Red Hat 7.1 and glibc 2.2.3. It would take a few rounds to bring it up to date. The fact that neither they nor Broadcom have anything more recent disturbs me a bit as the thought that springs to my mind (given the headaches I've had so far) is that maybe they haven't been able to. After giving the crosstools another go, and seeing if I can get the Debian packages installed, I'm going to see if OpenEmbedded offers any possibilities. Gentoo would be nicer, as that doesn't need a pre-existing system, but Gentoo don't do MIPS64 distributions. Jonathan Day --- Richard Sandiford <[EMAIL PROTECTED]> wrote: > Further to Eric's good advice: > > Do you already have access to a mips64 version of > glibc? (You said in > your message that you'd tried a native build, but I > wasn't sure whether > that was using a 32-bit OS or a 64-bit OS) > > It's tricky to build a toolchain and glibc in tandem > (i.e. when neither > is available beforehand), and like Eric says, > crosstool is probably the > best thing to use for that. (Although to be honest, > I don't use crosstool > myself, so I'm not 100% sure whether it supports > mips64 or not.) > > On the other hand, if you already have access to a > 64-bit glibc, you > should be able to build the toolchain in the same > way as any other > version of gcc. So if you do have access to a > 64-bit glibc: which > version(s) of gcc are you trying to build, and what > errors do you get? > > Richard > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Question regarding compiling a toolchain for a Broadcom SB1
--- Kai Ruottu <[EMAIL PROTECTED]> wrote: > So, Jonathan, if you need to get a knife (glibc) for >producing your own hammer (gcc), just ask someone to >give that knife and produce your own hammer first with >that borrowed knife. And then produce your own knife >using your self-made hammer and later the final hammer >with your self-made knife... After customizing your >hammer and knife many times you soon forget how on >earth you managed to get the first hammer and knife >and what the heck, who even cares about that ! I agree with you completely. Ok, does anyone have a MIPS64 binary of glibc that they could run me a copy of? Actually, as you'll see later in my post, a copy of binutils would be better, as that seems to be where the MIPS board is suffering the most problems. I -think- I need a chisel, as well, though. On producing the bootstrap GCC cross-compiler, trying to compile with it produces the error that it can't find crti.o, crtn.o or crt1.o. IIRC, these are produced when compiling GCC, but the GCC in CVS does not have the source file for crt1.c for MIPS, does not compile crti.c by default and the assembler choked on crtn.o I do have old versions of these files on the native MIPS64 environment, so it does depend a litte on whether these files have changed significantly or not. I can build a cross-assembler with no problems. That part isn't a problem. The problem is that the compiler and assembler on the MIPS board are broken and won't compile a binutils tarball or a copy fresh from CVS. (The installed linker is rejecting object files produced by the installed assembler as invalid, and the installed assembler is rejecting assembly files in GCC as invalid.) The approach I've been following is to say "Ok, the tools on the board are compiling some things but not others - it would be best to replace them with something reliable. Commercial binaries seem to be all ancient, so it looks as though I'll need to do SOME rolling of my own, at least. If I can build a functional cross-compiler, I can use that to build a native compiler, which I can then move over and build what I need - treat it as a blank system, since I have no pre-installed code I can trust and no obvious repositories I can use to grab binaries from." I've been wanting to do a "roll-your-own" partly because I'm a stubborn SOB, partly because I can then tune it to the precise environment and partly because if I can't build a toolchain because of missing/uncompiled files, then there's a bug in the code or a bug in the method, either of which is important to know and fix. (There's also a lot to do with the fact that I actually enjoy building things from source when I can. It's just a pain in the neck when either the instructions are out of date OR there is unintended behaviour. Oh, this sort of level of development will never be on the same level as building an Airfix model, but the parts should all be there and the glue shouldn't run off with the table leg.) Jonathan __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Question regarding compiling a toolchain for a Broadcom SB1
Here's the web link to all of the patches needed by the Linux From Scratch group. http://documents.jg555.com/cross-lfs/mips64-64/materials/patches.html I'm doing a build from the binutils, gcc and glibc from CVS, for an initial run. Results so far: Binutils patches cleanly, using the patch on file. It seems to build fine, when patched, but until all stages are complete, there's no easy way to verify that. GCC won't take the Posix patch and some of the other patches need massaging, but there doesn't seem to be any major problems. HOWEVER, this does say that you'd best stick with the intended version (GCC 4.0.1) for your build scripts. Glibc will take the 64-bit fixes but all other patches are rejected. It failed on the forced unwinding test, when configuring. According to the LFS docs, NPTL is broken for MIPS64, but I don't know if that is still the case. I decided to backtrack to the glibc that works, according to the LFS, and have classed the status of Glibc for MIPS64 as uncertain. --- Daniel Kegel <[EMAIL PROTECTED]> wrote: > Jonathan Day wrote: > > Crosstool, for example, only supports 32-bit MIPS > - > > and even then the build matrix is a pretty sh ade > of > > red for the most part. > > [ The build matrix: > http://kegel.com/crosstool/current/buildlogs/ ] > > There are quite a few combinations that build for > 32-bit mips with crosstool, e.g. > mips-gcc-3.2.3-glibc-2.2.5 > mips-gcc-3.2.3-glibc-2.3.2 > mips-gcc-3.3.6-glibc-2.2.5 > mips-gcc-3.3.6-glibc-2.3.5 > mips-gcc-3.4.4-glibc-2.3.2-hdrs-2.6.11.2 > mips-gcc-3.4.4-glibc-2.3.5-hdrs-2.6.11.2 > mips-gcc-4.1-20050702-glibc-2.3.2-hdrs-2.6.11.2 > mips-gcc-4.1-20050709-glibc-2.3.2-hdrs-2.6.11.2 > so the situation isn't that dire. > > For the record, I would be more than happy to add > mips64 support to crosstool. > http://www.linux-mips.org/archives/linux-mips/2005-07/msg00189.html > http://documents.jg555.com/cross-lfs/mips64-64/cross-tools/glibc.html > http://documents.jg555.com/cross-lfs/mips64-64/cross-tools/gcc-final.html > mentions some patches that might be needed. > I haven't had time to chase them down and add them > to crosstool, > but if anybody else felt like it, I'd gladly accept > the patches. > I'm sure a lot of mips64 users would be very happy. > - Dan > > > __ Click here to donate to the Hurricane Katrina relief effort. http://store.yahoo.com/redcross-donate3/
Re: Question regarding compiling a toolchain for a Broadcom SB1
Ok, I -think- I've found one problem. Identifying the processor as an SB1 may be producing a confused result. Both binutils and glibc's configure scripts will see it as a mips32, because it does not start off with mips64 in the name. However, GCC's configure scripts expands the name to mipsisa64sb1, which implies it is seeing the processor as a 64-bit architecture. None of the above test for whether the sb1-fix flag needs to be set (which fixes a couple of floating-point bugs in the processor), though I think I'm safe in assuming that the compiler and binutils won't be doing much in the way of floating-point arithmetic and I can worry about glibc's FP code when I get to the point of building a native copy. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
