This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Vr4131 porting issues


"Jurica Baricevic" <jura at INTESIS dot hr> writes:

> Nick Garnett wrote:
> > The first thing to note is that the vr4300 targets were all compiled
> > with a special version of the compiler, the mips64vr4300-elf
> > variant. The default eCos configuration assumes that compiler and GDB
> > to work properly.
> >
> > I cannot recall now whether this was a build option for the
> > public version, or was a Cygnus/Red Hat internal target that was
> > shipped to NEC specifically for their customers.
> >
> > So one thing you could try is building the tools with
> > --target=mips64vr4300-elf.
> 
> Thanks. I'll put this to my list of trials.
> 
> 
> > It is division by zero. The cause is probably a mismatch between the
> > way that libgcc was built and the calling code: the -mgp32 is probably
> > to blame.
> >
> > However, your RedBoot B seems a more promising route to take.
> >
> 
> Hm. I would rather stick to -mgp32 since all other MIPS targets seem
> to take that route. Nevertheless, I wouldn't be sad if the -mgp64
> gets working either :-)
> 
> 
> > Please bear in mind that neither RedBoot nor eCos has ever been tested
> > on a true 64 bit architecture. We have run successfully in 32 bit mode
> > on various 64 bit machines. So, there may be some unexpected gotchas
> > in the code.
> 
> Thanks.
> Just to clarify some 64/32-bit things. If I noticed well - the Vr4300
> eCos is by default switching CPU in 64-bit access mode (bit KX in
> status register), but the C code is built with -mpg32 to avoid usage of
> 64-bit instructions. Some assembler routines use ld/sd though. Am I right?

Yes. eCos and RedBoot continue to run in 32 bit mode, but we context
switch the whole 64 bit machine state. This was originally as a result of
some bugs in the toolchain: the -mgp32 wasn't being passed on to the
assembler, so it still thought it was building for 64 bits and
generated some 64 bit instructions. 

> 
> Do you maybe have some idea what could be 64/32 bit architecture
> issues in eCos?

If I knew that I would fix them :-)

The main problem areas are in code that manipulates addresses and
data. We use the CYG_ADDRESS and CYG_ADDRWORD types for this, but
these are currently defined as 32 bit values for all targets. Moving
them to 64 bits might introduce size and alignment issues in a number
of data structures. Also, some imported code, like the BSD stack, may
not be 64 bit clean.

> > I've seen this before. Again it goes back to that mips64vr4300-elf
> > toolchain, which was configured to support 64 bit registers. The
> > default configuration only supports 32 bit registers in the register
> > dump.
> >
> 
> Hm. I thought that my toolchain should support 64-bit too,
> but I am not sure any more.

The toolchain, in the form of the compiler, assembler, linker,
probably can. The problem is with what GDB expects in the remote
protocol that counts here. 

> 
> 
> > The simplest approach to fixing this is to take a look at
> > hal/mips/arch/current/include/mips-stub.h. At the front of this file
> > is a rather nasty set of ifdefs that select the GDB register size. You
> > need to find out which option it is selecting here, you might be
> > getting caught by the __mips64 case. In this case you probably need to
> > add a case before that to catch it for your platform and set the
> > register size to 4.
> 
> You are right. The __mips64 is the case (which, by the way, looks the same
> to me as VR4300).

It is, we were slowly moving to a more generic solution for this issue
using the __mips64 macro and the
CYGINT_HAL_MIPS_STUB_REPRESENT_32BIT_AS_64BIT option. But we haven't
quite got there yet.

> 
> Following your advice - GDB and Redboot started to understand each other :-)
> I was able to connect and download some dummy code properly. So, thanks to
> you,
> now I may switch to the next step - trying to run/debug some eCos
> applications
> (device drivers, interrupts, etc.)
> The only minor problem I noticed was in the connection process (it is a bit
> slow):
> 
> [gdb-session start]
> 

[snip unhappy gdb]

> 
> [gdb-session end]
> 
> I don't know is it normal, but at least - it gets connected at the end.
>

That's not right at all, it should connect smoothly. Does this still
happen now that you are using the mipsisa32-elf toolchain?


-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]