[9fans] P9P on Lemote Yeeloong

[9fans] P9P on Lemote Yeeloong

[lucio]

I thought things were running too smoothly.  I got P9P to compile on
the Lemote Yeeloong with only very frequent ocurrences of warnings
(they seem like compile-time warnings) to the effect that each of
getcontext, makecontext and swapcontext "is not implemented and will
always fail".

Now, the Yeeloong is a notebook based on a MIPS cpu and endowed with
Open Architecture, Open BIOS (called PMON) and Linux (Debian).  The
man page for getcontext() seems to suggest that it exists, but
executing, say, acme fails with:

"threadalloc getcontext: function not implemented"

So close to getting there, but I must be missing something.  Does
anyone know what?

++L

Re: [9fans] P9P on Lemote Yeeloong

[Bakul Shah]

On Wed, 13 May 2009 21:57:11 +0200 lucio@proxima.alt.za  wrote:
> I thought things were running too smoothly.  I got P9P to compile on
> the Lemote Yeeloong with only very frequent ocurrences of warnings
> (they seem like compile-time warnings) to the effect that each of
> getcontext, makecontext and swapcontext "is not implemented and will
> always fail".
>
> Now, the Yeeloong is a notebook based on a MIPS cpu and endowed with
> Open Architecture, Open BIOS (called PMON) and Linux (Debian).  The
> man page for getcontext() seems to suggest that it exists, but
> executing, say, acme fails with:
>
> "threadalloc getcontext: function not implemented"
>
> So close to getting there, but I must be missing something.  Does
> anyone know what?
>
> ++L
>

See $PLAN9/include/u.h. You may need to add something to the
/* OS-specific crap */ section. Adding

#include <pthread.h>
#define PLAN9PORT_USING_PTHREAD 1

for your version of linux just might do the trick.

Re: [9fans] P9P on Lemote Yeeloong

[Latchesar Ionkov]

The glibc on your notebook probably doesn't have getcontext
implemented. Google for "glibc mips getcontext".

Thanks,
    Lucho

On Wed, May 13, 2009 at 1:57 PM,  <lucio@proxima.alt.za> wrote:
> I thought things were running too smoothly.  I got P9P to compile on
> the Lemote Yeeloong with only very frequent ocurrences of warnings
> (they seem like compile-time warnings) to the effect that each of
> getcontext, makecontext and swapcontext "is not implemented and will
> always fail".
>
> Now, the Yeeloong is a notebook based on a MIPS cpu and endowed with
> Open Architecture, Open BIOS (called PMON) and Linux (Debian).  The
> man page for getcontext() seems to suggest that it exists, but
> executing, say, acme fails with:
>
> "threadalloc getcontext: function not implemented"
>
> So close to getting there, but I must be missing something.  Does
> anyone know what?
>
> ++L
>
>
>

Re: [9fans] P9P on Lemote Yeeloong

[Russ Cox]

I don't know that p9p has ever been built
on a MIPS machine, so you might run into
more problems after this one.

You are almost certainly running Linux 2.6
so you shouldn't need to edit u.h -- it should
be using pthreads already.

You probably need to edit src/libthread/sysofiles.sh
to add a

case mips-Linux-2.6.*)
    echo pthread.o Linux-mips-context.o
    ;;

Then you'll need to write Linux-mips-context.S and mips-context.h
to provide useful versions of getcontext and setcontext
and change threadimpl.h to use them on MIPS (like it does
for __APPLE__ and __OpenBSD__).

I looked around but I don't think I have any such
implementations lying around.  They're not too hard:
just save and restore every register (technically,
just the callee-saves, but I'm too lazy to look up
which ones are which and too paranoid to trust
them not to change).

Russ

Re: [9fans] P9P on Lemote Yeeloong

[lucio]

> See $PLAN9/include/u.h. You may need to add something to the
> /* OS-specific crap */ section. Adding
>
> #include <pthread.h>
> #define PLAN9PORT_USING_PTHREAD 1
>
> for your version of linux just might do the trick.

Could this cause what looks to me like a compiler error?  I think P9P
knows to use pthreads, but I'm prepared to be surprised.

I will be looking into it, thank you for the pointer.

++L

Re: [9fans] P9P on Lemote Yeeloong

[lucio]

> I don't know that p9p has ever been built
> on a MIPS machine, so you might run into
> more problems after this one.

I'm OK with that, although I don't know MIPS assembler, nor anything
about the MIPS instruction set (can't be too hard!) or its
architecture.  I presume I can copy bits from the Plan 9 code and more
from the APE library, allowing for GAS's slightly different syntax.

Thank you Russ for the information, I guess I know what I'll be doing
the rest of today.

Should this be of interest to anyone, my hope is that once I have P9P
running on MIPS, I will be able to adjust the Plan 9 kernel sources to
compile under GCC to bootstrap Plan 9 on the Yeeloong.  No doubt there
will be question that this list will be asked to assist with :-)

++L

Re: [9fans] P9P on Lemote Yeeloong

[lucio]

> The glibc on your notebook probably doesn't have getcontext
> implemented. Google for "glibc mips getcontext".

Wow, that's a fortunate hit!  Very first entry and there stands a bit
about backporting getcontext for glibc for the loongson, which I think
is the name of the CPU in the Yeelong (loongson 2F, I think it is
called).  Thank you, Lucho.

++L

Re: [9fans] P9P on Lemote Yeeloong

[Charles Forsyth]

>I will be able to adjust the Plan 9 kernel sources to
>compile under GCC to bootstrap Plan 9 on the Yeeloong.  No doubt there
>will be question that this list will be asked to assist with :-)

since the hard part is writing drivers, just do a normal port using v[acl].
not fussing about with all the other things that will otherwise go wrong
will allow you more time to write those drivers.

Re: [9fans] P9P on Lemote Yeeloong

[Charles Forsyth]

>So you are a bit out of luck here on MIPS [for 64-bit compilers]

64-bit compilers for 64-bit RISC architectures are fairly easy,
at least in the sense that we know what to do. amd64 wasn't quite
as easy because it was non-RISC (and as weird as x86),
had a completely different FP model, and was the first full 64-bit port,
requiring some decisions about the model and (in the end) tweaks to /sys/src/cmd/cc.
(alpha was a 64-bit processor but ran with 32-bit pointers.)
that's all done. based on that, power64 was mostly done in about a week.
it hasn't been much used since then, and might need a bit more work,
but that will be small.  i wouldn't expect much more is required for 64-bit mips.

Re: [9fans] P9P on Lemote Yeeloong

[lucio]

> There are versions of Plan 9 compilers that support both those formats
> -- perhaps it won't be as hard as you expect.
> BlueGene boots Plan 9 from ELF binaries for instance.
>
I'll have a good look, I wasn't expecting that.  Right now, I want to
clear up P9P on the Lemote, if at all possible.  Once I'm sure of
where that is going, I'll consider finding out how to generate ELFes
under Plan 9 for the MIPS platform.  I'll try not to be stubborn.

> There are 64-bit compilers available for Plan 9 as well (for specific
> architectures, namely x86_64 and ppc64).  So you are a bit out of
> luck here on MIPS (unless Brzr has a MIPS64 compiler I've forgotten
> about).

I think Steve Simon is right and there is a partial implementation of
the MIPS-64 compiler lurking.  But I don't think I'll be the one to
complete it, compiler construction is not one of my (scarce) strong
suits.

++L

Re: [9fans] P9P on Lemote Yeeloong

[Steve Simon]

>  So you are a bit out of
> luck here on MIPS (unless Brzr has a MIPS64 compiler I've forgotten
> about).

I'am sure somone was working on a mips 64 bit port to modern sgi hardware.
I haven't heard anything of this for a while but perhaps somone
will remember who it was.

-Steve

Re: [9fans] P9P on Lemote Yeeloong

[Eric Van Hensbergen]

On Thu, May 14, 2009 at 1:29 PM,  <lucio@proxima.alt.za> wrote:
>> since the hard part is writing drivers, just do a normal port using v[acl].
>> not fussing about with all the other things that will otherwise go wrong
>> will allow you more time to write those drivers.
>
> My take is perhaps flawed, but the way I see it, the BIOS, bootstrap
> loader and debugger (all rolled into PMON, supplied with source and
> ready for cross compilation on a Linux/386 platform) insists on ELF,
> optionally S-record format executables.
>

There are versions of Plan 9 compilers that support both those formats
-- perhaps it won't be as hard as you expect.
BlueGene boots Plan 9 from ELF binaries for instance.

>
> Now, I really don't mind hearing of different approaches, often these
> have turned out to be better than the dead end I had picked, so I'll
> keep that firmly in mind.  In this case there is a small additional
> advantage to go the ELF/GCC route, namely that I will be using a
> 64-bit compiler for the kernel itself.
>

There are 64-bit compilers available for Plan 9 as well (for specific
architectures, namely x86_64 and ppc64).  So you are a bit out of
luck here on MIPS (unless Brzr has a MIPS64 compiler I've forgotten
about).

     -eric

Re: [9fans] P9P on Lemote Yeeloong

[Steve Simon]

I thought the ethernet chip is supported in plan9 so that might be easy.

vl can generate elf files, these are targeted at sgi machines
but most of the groundwork should be there for you.

Failing this I am pretty sure I have a motorola S record generator somwhere,
I will convert the input side to plan9 a.out if I can find it.

IMHO v[cla] is the way to go.

-Steve

Re: [9fans] P9P on Lemote Yeeloong

[lucio]

> since the hard part is writing drivers, just do a normal port using v[acl].
> not fussing about with all the other things that will otherwise go wrong
> will allow you more time to write those drivers.

My take is perhaps flawed, but the way I see it, the BIOS, bootstrap
loader and debugger (all rolled into PMON, supplied with source and
ready for cross compilation on a Linux/386 platform) insists on ELF,
optionally S-record format executables.  It seems easier and more
beneficial to shoehorn the Plan 9 kernel sources into GCC (Russ has
already done a lot of the ground work for that) than to convert the
Plan 9 kernel binaries into ELF.  I'm not sure about S-record, I have
a feeling a lot will be lost in the translation.

Now, I really don't mind hearing of different approaches, often these
have turned out to be better than the dead end I had picked, so I'll
keep that firmly in mind.  In this case there is a small additional
advantage to go the ELF/GCC route, namely that I will be using a
64-bit compiler for the kernel itself.

That said, I'm still fighting with the thread context switch stuff:
there was some exciting stuff Lucho directed me to, but so far I seem
to be held back by the fact that what I found applies to Gentoo rather
than Debian.  I need to dig a little deeper.

Also, the 32-bit/64-bit question comes up again.  I don't know enough
about MIPS to do more than ponder over the likelihood of getting a
64-bit compiler running by the time I have the kernel ported.  I'm
putting that on the backburner.

As for drivers, I'm hoping that most of the drivers will be compatible
with their 386 versions.  There is source for Linux and there is
documentation (I have only found it in Chinese, but that's still
better than nothing and I have not looked very far).  I'm too far from
that bridge to focus on it at this point, I can only wish that I will
get to it any time soon.

But again, I'm willing to listen.

++L