[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [openrisc] binutils, gcc and Linux on the OpenRISC [repost]



On Monday 25 March 2002 20:05, you wrote:
> Hi Lee!
>
> > I had a few hours free, so I tried compiling binutils and gcc of
>
> or32-linux
>
> > (which is actually or32-unknown-linux-gnu).
> >
> > I had a few problems with binutils, but after changing the various
> > configuration files (most changing or32-*-*linux to or32-*-*linux* or
> > or32-*-*linux-gnu*) I managed to get all of binutils compiled.
>
> Yes, the trend is to use linux-gnu; we've always using shorter version
> or32-linux, like others do :)

or32-*-linux* marches both.

>
> > Q1: should I get an account to commit these (small) changes?
>
> Yes, it would be nice if you could update the CVS frequently, but please
> keep the old targets also.

Ok.

>
> For Linux you should import new module or1k/linux or or1k/linux-version

Should that be the whole kernel tree?  (about 120MB, and i'm on dialup  ;-), 
or just the or32 port (plus i386, sparc and m68k for reference) with the rest 
of the required files or just the or32 files?

>
> > After they where sucessfully installed, I tryed to compile gcc.  I didn't
> > have much luck.
> >
> > For target=or32-linux I get:
>
> <cut>
>
> > If I try with target=or32-elf I get:
>
> <cut>
> Both target should be very similar, I am not sure why there are
> differencies in
> outputs; I suspect you have problems with gcc/binutils configuration.
> --prefix=<dir> option with binutils/gcc configure should be the same and
> before
> building gcc you should export <dir>/bin. The reason for this is that
> <target>-gcc uses
> <target>-as, or if not found just 'as', which is in your case wrong
> assembler.
> If the problem still remains compile with -v (verbose) and -save-temps
> options,
> and submit more detailed problem report again.
> Look at script for building GNU utils on web site, so that you don't miss
> any steps.

I'll have another go when I get a few moments free.

> > Q3: Are there any documents about the whole system, processor, bus,
>
> memory,
>
> > everything?
>
> Good question. I am attaching Damjan's proposal of OpenRisc Reference
> Platform.
> Unfortunately it is not final yet, but it may be a good start.
> If you are not going to mess with HW, you just need to set the .cfg file
> for or1ksim.

That does help alot, thanks.


>
> > Q5: Anything else I should know before I start porting a week today?
> >
> :) I cannot remember anything, but feel free to ask anything when you
>
> bump into a problem.

I will.

> Maybe just a hint: be sure to use full debugging capabilities of or1ksim.
> e.g. l.nop instructions can be quite handy -- look in
> or1k/or1ksim/testbench/support.c
> you can connect gdb to or1ksim, however I would suggest to use executed log
> instead (look into or1k/or1ksim/sim.cfg how to enable it). Together with a
> good searcher/editor
> it is very powerful.

ok.

> Otherwise I don't think you really need the documentation, you will
> probably spend the
> most time figuring out how or1k works :)

I printed out the Architecture Manual and i've had a good read of it.  Most 
of it makes sense.

>
> > I look forward to starting shortly.
>
> And we look forward to working with you,
>
> Marko

Thanks.

Would someone else like to see if they can compile or32-linux binutil and gcc 
targets?  I will commit the fixed binutil files as soon as I get an account.

Later
Lee Begg
llnz@paradise.net.nz
--
To unsubscribe from openrisc mailing list please visit http://www.opencores.org/mailinglists.shtml