linux-mips
[Top] [All Lists]

Re: Arch/mips/kernel/vpe.c

To: Thiemo Seufer <ths@networkno.de>
Subject: Re: Arch/mips/kernel/vpe.c
From: Ralf Baechle <ralf@linux-mips.org>
Date: Mon, 7 Jan 2008 16:18:35 +0000
Cc: KokHow.Teh@infineon.com, linux-mips@linux-mips.org
In-reply-to: <20080105170546.GG22809@networkno.de>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <31E09F73562D7A4D82119D7F6C1729860320EADA@sinse303.ap.infineon.com> <20080105170546.GG22809@networkno.de>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.5.17 (2007-11-01)
On Sat, Jan 05, 2008 at 05:05:46PM +0000, Thiemo Seufer wrote:

> >     I am working on MIPS34KC with APRP kernel and I use uclibc
> > gccc-3.4.4 to build applications to run on VPE1. The present
> > implementation of VPE loader is limited to a few relocation types which
> > are used when mips_sde compiler is used. However, the relocatable binary
> > churn out from my uclibc-gcc-3.4.4 has more other relocation types than
> > the ones defined in arch/mips/kernel/vpe.c, especially those with GOT
> > relocation types. I have taken a look at the System V ABI Third Edition
> > but if anybody has any code reference and pointers to how each
> > relocation types should be implemented in C-code, it would be very
> > helpful.
> 
> The most likely place to look at would be the binutils source code. That
> said, you can probably get away without enhancing the VPE loader by using
>   a) fully linked (non-relocatable) executables, or
>   b) non-PIC code, like SDE does
> 
> Regardless of your choice, you will have to make sure the uclibc toolchain
> doesn't use any libraries which need Linux facilities, as the bare-metal
> environment on VPE1 doesn't provide them. For that reason I believe you
> are better of with SDE or a similiar mips*-elf configured toolchain.

I'm tempted to replace the existing vpe loader with something like the 2.4
version of insmod which does all the relocation handling in userspace and a
device file which make the vpe memory available to userspace for the loader
to write to.  Or something like spufs.

  Ralf

<Prev in Thread] Current Thread [Next in Thread>