[ECOS] Vr4131 porting issues

Jurica Baricevic jura@INTESIS.hr
Tue Mar 18 15:19:00 GMT 2003


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.

------------
[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.


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

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.

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

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]
(gdb) target remote com1
Remote debugging using com1
Ignoring packet error, continuing...
Remote packet too long:
0000000000000000000000aaffffffff0100000000000000c88c0180
ffffffff707c0080fffffffff0ffff80ffffffffb0f30180ffffffff0000000000000000b0f3
0180
ffffffff0a000000000000000000000000000000000000000000000093000000000000000000
0280
ffffffff9bb8c0bffffffffffcff0080ffffffff020000000000000000060080ffffffff0000
0080
ffffffff000000000000000000060080ffffffff3d0000000000000000000280fffffffffdff
ffff
ffffffffd09e676223730d4eef4f0aea68fdb13b000000000000000000060080ffffffffb0f3
0180
ffffffffd0ffff80ffffffff17d4c3120def5f70a80f0080ffffffff8204001000000000f401
0000
000000000000000000000000ffb379b7b7a76f792480000000000000707c0080ffffffff0000
0000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000
0000000000000000000000000000000000000000000000000000000
[excerpt-end]

If it could help to somebody I might send output with "set debug remote 2".

------------

Since we are stuck with the issue and running out of ideas :-( any help or
hint is appreciated.


Thanks,
Jura



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



More information about the Ecos-discuss mailing list