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:

> Hi!
> 
> We are trying to run Redboot/eCos on our own HW with VR4131 CPU.
> We are using:
> -latest eCos sources
> -latest cygwin
> -GCC 2.95.3 (configured for mipsel-elf)
> -binutils 2.11.2
> -insight 5.1.1
> 
> The HAL was adapted to the Vr4131 (the Vr4300 port was used as the baseline)
> and our platform and after some time Redboot started to give first signs of
> life. Currently, we have two differently built RB versions (using different
> build options) and both have some problems.
>

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.


> ------------
> [Redboot A]
> Built with the following options (among all others):
> -mcpu=r4100 -mips3 -mpg32
> 
> A1. The Redboot works until the first diag_printf() with number format (i.e.
> %d, %x, etc). There it 'gets stuck'. Unfortunately, this happens at the
> early start of Redboot (i.e. when RAM address range is printed). Debugging
> RB more thoroughly, it seems that the LIBGCC.A for ISA3 is the one that
> generates problems. Namely, in the first 64-bit number division/modulo
> operation in diag.cxx (which is simulated by LIBGCC), CPU throws an BREAK
> exception. Disassembling __umoddi3() (which causes problem) from LIBGCC
> showed that it has some BREAK instructions indeed (division by zero?).
> However, I have no idea why the code would ever come to that point.
> 

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.

> 
> ------------
> [Redboot B]
> Built with the following options (among all others):
> -mcpu=r4100 -mips3 -mpg64
>

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.

> B1. When general purpose registers are set to be used as 64-bit (to avoid
> usage of some LIBGCC functions) - compilation throws a few warnings in the
> GDB stubs code.

This is expected. We deliberately chose not to over-edit the stubs, so
we could re-import the file more easily from libgloss.

> 
> B2. The Redboot works perfectly in CLI mode. All interfaces and commands are
> working fine (even Networking over CS8900).

This is good, and is clearly the way to go.

> 
> B3. In GDB mode it seems that debugger and Redboot GDB stubs do not
> understand each other very well (shouldn't GDB support 64-bit registers?).
> Here's an excerpt of one GDB session:
> 
> [excerpt-start]

[snip]

> [excerpt-end]
> 
> If it could help to somebody I might send output with "set debug remote 2".
> 

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.

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.

Alternatively, the mips64vr4300-elf toolchain configuration might be
the way to go.

Hope this helps.

-- 
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]