RE: [ECOS] Vr4131 porting issues

["Jurica Baricevic" <jura at INTESIS dot hr>]

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?

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


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

Ok. Thanks.


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

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]

(gdb) set debug remote 2
(gdb) target remote com1
Remote debugging using com1
Sending packet: $Hc-1#09...Ack
Timed out.
Timed out.
Timed out.
Ignoring packet error, continuing...
Sending packet: $qC#b4...Ack
Packet received: E02
Sending packet: $qOffsets#4b...Ack
Packet received:
Sending packet: $?#3f...Ack
Packet received: S02
Sending packet: $Hg0#df...Ack
Packet received: OK
Sending packet: $g#67...Ack
Packet received:
0000000000000000000000aaffffffff0100000000000000c88c0180fffffff
f607c0080fffffffff0ffff80ffffffffb0f30180ffffffff0000000000000000b0f30180fff
ffff
f0a0000000000000000000000000000000000000000000000930000000000000000000280fff
ffff
f0e000000000000000f30000000000000020000000000000000060080ffffffff00000080fff
ffff
f000000000000000000060080ffffffff3d0000000000000000000280fffffffffdfffffffff
ffff
fd09a666623731d5e8f4e0aea68ffb5bb000000000000000000060080ffffffffb0f30180fff
ffff
fd0ffff80ffffffff8ff4c31b89ff5f78ec0f0080ffffffff82040010000000000552b81e1d0
0000
00000000000000000f2a069b7a4250f792484000000000000607c0080ffffffff00000000000
0000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000
00000000000000000
0xffffffffffffffff in ?? ()

[gdb-session end]

I don't know is it normal, but at least - it gets connected at the end.


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

Ok.

> Hope this helps.

It helped a lot.


Thank you very much,
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