Subject: 64 bit build fails

From: Carsten Langgaard <[email-masked]>
Date: Wed, 13 Dec 2000 16:58:52 +0100

I'm trying to build a 64bit kernel, but it fails with following message:

mips64-linux-gcc -D__KERNEL__
-I/home/soc/proj/work/carstenl/sw/linux-2.4.0/include -Wall
-Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing
-mabi=64 -G 0 -mno-abicalls -fno-pic -Wa,--trap -pipe -mcpu=r8000 -mips4
-Wa,-32   -c head.S -o head.o
head.S: Assembler messages:
head.S:69: Error: Missing ')' assumed
head.S:69: Error: Missing ')' assumed
head.S:69: Error: Missing ')' assumed
head.S:69: Error: Missing ')' assumed
head.S:69: Error: Missing ')' assumed
head.S:69: Error: Missing ')' assumed
head.S:69: Error: illegal operands `dli'
head.S:107: Error: Missing ')' assumed
head.S:107: Error: Missing ')' assumed
head.S:107: Error: Missing ')' assumed
head.S:107: Error: Missing ')' assumed
head.S:107: Error: Missing ')' assumed
head.S:107: Error: Missing ')' assumed
head.S:107: Error: illegal operands `dli'
head.S:109: Error: Instruction dsll requires absolute expression
head.S:109: Error: Instruction dsll requires absolute expression
make[1]: *** [head.o] Error 1
make[1]: Leaving directory
`/home/soc/proj/work/carstenl/sw/linux-2.4.0/arch/mips64/kernel'
make: *** [_dir_arch/mips64/kernel] Error 2

What are this macro doing ?

.macro GET_NASID_ASM
 dli t1, LOCAL_HUB_ADDR(NI_STATUS_REV_ID)
 ld t1, (t1)
 and t1, NSRI_NODEID_MASK
 dsrl t1, NSRI_NODEID_SHFT
 .endm

/Carsten

--
_    _ ____  ___   Carsten Langgaard   Mailto:[email-masked]
|\  /|||___)(___   MIPS Denmark        Direct: +45 4486 5527
| \/ |||    ____)  Lautrupvang 4B      Switch: +45 4486 5555
  TECHNOLOGIES     2750 Ballerup       Fax...: +45 4486 5556
                   Denmark             http://www.mips.com

---

From: Ralf Baechle <[email-masked]>
Date: Thu, 14 Dec 2000 21:59:33 +0100

> head.S:69: Error: Missing ')' assumed

Looks like an attempt to build a 64-bit Indy kernel.  Various people working
on the Origin support have completly broken the support for anything else in
their battle tank-style approach ...

  Ralf

---

From: Carsten Langgaard <[email-masked]>
Date: Fri, 15 Dec 2000 08:45:35 +0100

> their battle tank-style approach ...

Ok, that explains why a lot of things are broken.
So who will be responsible for fixing all the broken pieces ?

---

From: "Kevin D. Kissell" <[email-masked]>
Date: Fri, 15 Dec 2000 09:24:22 +0100

> So who will be responsible for fixing all the broken pieces ?

In the absence of the SGI people being directed to do a
clean job, I suppose the problem falls to those who have
an interest in a clean and portable 64-bit MIPS kernel.
That would include MIPS, of course.  But what about the
rest of you - could we see a show of virtual hands?  I
know that TI has both 4K and 5K licenses, and may
want to be able to exploit the 64-bit capability of the 5K
under Linux.  And the guys doing the Vr41xx ports may
also be interested.  Anyone else?  Those of you with
R4K-based DECstations, perhaps?  Software shops
looking to support high-end embedded MIPS in set-tops?

Another aspect of this is that, in the newer MIPS
designs that conform to the MIPS64 architecture spec,
it is finally possible to cleanly seperate the use of
64-bit data types from the use of 64-bit virtual addresses.
The processors in the SGI platforms do not have this
capability, and it would be a lot to ask of the people
doing 64-bit Linux for Origin etc. to treat the addressing
and data aspects orthogonally.  I haven't checked the
code, but I would imagine that we will have to go in
and redo things from that perspective as well.

            Regards,

            Kevin K.

---

From: Ralf Baechle <[email-masked]>
Date: Fri, 15 Dec 2000 16:20:23 +0100

> So who will be responsible for fixing all the broken pieces ?

This is the question you'd ask a company.  This is Free Software, not some
company's product ...

  Ralf

---

From: Ralf Baechle <[email-masked]>
Date: Fri, 15 Dec 2000 16:32:08 +0100

> and redo things from that perspective as well.

That's one of the plans I have; even in the absense of these new MIPS64
features separation of these new features makes sense.  One of the plans
on my agenda is for example the introduction of 2-level pagetables for
mips64 which will eleminate much of the extra price the 64-bit kernel
currently has to pay.

  Ralf

---

From: PianoMan <[email-masked]>
Date: Fri, 15 Dec 2000 17:28:13 -0500 (EST)

> looking to support high-end embedded MIPS in set-tops?

I took a crack at this a while back trying the non-brute force
approach.  However, I'm only interested in it as a hobby (I have an I2
R4400, and I'd like to get into some embedded work with the SiByte chip
when it comes out).  I was trying to make the computer look like a single
node (assigning a NASID of 0, etc..), but i got bogged down in the page
vs. node stuff before i got to far into it.  I'd be willing to help and
test again, but i have limited time now, unfortunately.

I was going for functionality, not speed, obviously ;)

john.c

- --
John Clemens           BS, Computer Engineering, RPI 2000
[email-masked]    at home - Parallel Computer Researcher/Hobbist
[email-masked]        at work - Kernel Engineer

---

From: Thiemo Seufer <[email-masked]>
Date: Sun, 17 Dec 2000 21:19:31 +0100

Carsten Langgaard wrote:
[snip]
>Ok, that explains why a lot of things are broken.

You might be interested in some work i have done [1] to create a 64-bit
kernel for SGI IP28 aka Indigo2 Impact. Don't expect it to be less
broken, it basically does an controlled crash at the very beginning of
kernel initialization.

(The IP28 Firmware doesn't like 32-bit ELF or even ecoff kernels.)

>So who will be responsible for fixing all the broken pieces ?

The one who asks about it, i assume. ;-)

[1] http://www.csv.ica.uni-stuttgart.de/homes/ths/linux-mips/

Thiemo

---

From: Carsten Langgaard <[email-masked]>
Date: Mon, 18 Dec 2000 09:11:38 +0100

> This is the question you'd ask a company.  This is Free Software, not some

What I mean is that we need some discipline, as you mention yourself, it is
unfortunate with this battle tank-style approach.
And I think you do a pretty good job trying to make the rest of the code as clean
as possible.
Of course some time it is a little bit annoying you doesn't just accept my patches
:-)
Just kidding, I think that's the right way to do things.

I was just hoping that the 64bit code was in the same condition as the rest of the
code.

/Carsten

---

From: Ralf Baechle <[email-masked]>
Date: Tue, 19 Dec 2000 15:47:59 -0200

On Mon, Dec 18, 2000 at 09:11:38AM +0100, Carsten Langgaard wrote:

> Of course some time it is a little bit annoying you doesn't just accept
> my patches :-)  Just kidding, I think that's the right way to do things.

Actually I tried to apply the patch but patch thinks your patch isn't a valid
patch file ...

> I was just hoping that the 64bit code was in the same condition as the
> rest of the code.

Depends.  It's running fairly well on Origins; nobody made a more than
halfbreed attempt to support IP22 for mips64, so what you see was kind of
what had to be expected.

  Ralf