[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
CPU model for efi332
- Date: Mon, 13 Sep 1999 17:25:49 -0700
- From: mcollins at wdc.sps.mot.com (Michael Collins)
- Subject: CPU model for efi332
I'm trying to put RTEMS onto a board we're using which is similar
to efi332. My boards use an MC68331, which differs from the MC68332
only in the timer modules. The timer used by RTEMS is within the
SIM, so this is not affected.
My code is ROM-based without a debugger, so I've had to do some
work on the initialization routines. These are confirmed to
initialize the chip select registers, set an initial stack pointer,
and copy static data (linked at the RAM addresses) from ROM. As
much as possible, I stuck with the code from the efi332 package,
making judicious changes only as required.
When I reached the point where the code ran through all the
initialization successfully, I saw output at the serial port
indicating that I was getting illegal instruction exceptions.
I added my own exception handler to output more detailed diagnostic
information, and found a stack frame which looked to indicate
a bftst (bit field test) instruction. That's an '020 instruction
not supported by CPU32 used in the MC6833x parts. I found in
CPU_FLAGS is set to -m68020 because "my gas does not grok -m68332".
Hmm. My CPU32 does not grok bftst.
I changed the flags to -mcpu32 (which my gas does grok), and
the generated code is indeed different, without bftst instructions.
The code now runs further, but still gets an illegal instruction
exception. This one I don't get. objdump -d displays the following
at what I'm reasonably certain is the fault address:
2738: 4afa 60fe tas %pc@(8838 <.eb+0xa>)
This address appears to be in the Spurious_Isr function.
Two things. One, I'm not entirely certain that I've got the right
address, as the stack frame gets rather complicated between the time
of the fault and the time my exception handler runs. My first
priority is to inspect the code and be sure I'm looking in the
right place. Two, I can't make sense of that op-code (0x4afa).
According to the 68k family reference, bit 1 should be cleared
if the mode bits (bits 5-3) are all ones. The only other candidate
instruction is tst, but in that case, bits 6 and 7 cannot both
So it looks as though this may in fact be an illegal instruction.
Any ideas? I'm going to make sure I'm looking at the right stack
frame, but thought it worth throwing this out in case it looks
familiar to anyone.
-- MC --