MVME2304 Exception 3

[Till Straumann]

Exception 3 means that the MMU has no mapping (DBAT or
page hash table entry) to access the desired address in
the desired way (read vs. write).

Joel is right - most likely, the memory size is
not guessed accurately.

Paul - can you, please, provide a full log of
all messages printed (from PPCbug after powerup
through GeSys reporting exception 3 (including the
register and stack dumps) ? With this information,
I'll be able to help you.

Since you have >32M of memory, I want to remind
you of the usual problem: gcc, by default, does
not generate far calls and hence run-time loading
of code fails if the loaded objects end up
(CEXP uses heap memory for all segments) more
than 32M apart from code they reference.
As a work around, I can provide you with a patch
that restricts memory to 32M at startup. The
patch implements a trivial 'sbrk()', so additional
memory becomes available after you use up the first
32M. This way, you can load all of your code
(EPICS application) first (i.e. before allocating
large amounts of memory). The same problem exists
with vxWorks, BTW...


Regards
-- Till

Joel Sherrill wrote:
> Paul D Jines wrote:
> 
>>
>>
>>
>> Hello -
>>
>>    We are trying to run RTEMS on a MVME2304-0143
>> and are experiencing Exception 3 errors.  Any help or
>> advice anyone could give would be greatly appreciated.
> 
> 
> Isn't exception 3 a protection violation?  If so, then
> I would be betting on an access to an invalid address.
> My quick perusal of the documentation for a different
> PowerPC model hints that it is more likely to be a write
> since it could also be to a read only region of memory.
> 
>>   Our setup and problem description are:
>>
>> - The card is a MVME2304-0143, which, if I am correct, is
>>   the same as a MVME2308, a 2307 with twice the memory
>>   (128MB). It is the only card in the crate.
>> - We are using the MVME2307 BSP, and have configured the
>>   card as per the README.MVME2300 and BOOTING files.
>> - The exceptions occur while in the routine memset, called
>>   from RTEMS_Malloc_Initialize.  The strange thing is that
>>   it occurs in both our build of small EPICS applications
>>   and in Dr. Straumann's GeSys prebuilt binary (version
>>   20030731).
> 
> 
> One side-effect of RTEMS_Malloc_Initialize is that is zeroes
> all of the heap memory.  I don't recall the exact memory layout
> on these BSPs, but this all would leave me to believe that
> the probes in the BSP that determine how much RAM you have
> are spuriously returning the wrong amount.
> 
> Just checked and I think the heap is assigned to the end
> of RAM (high addresses) on this BSP.  So an autoprobe of
> RAM size failing to give a correct value would definitely
> do this.
> 
> Till.. any ideas on why this might be happening?  Since they
> are using your binaries, you might have to help them turn on
> some debugging in the BSP startup.
> 
>> - We have tried several snapshots of RTEMS (our current
>>   version is 4.6.0pre4 with the prebuilt 3.2.2 gcc, newlib
>>   1.11.0-2, and 2.13.2.1-1 binutils).  We have tried 3.2.3
>>   and 3.2.1 gcc, but with the same result.
>> - The exception 3's occur most of the time, but maybe 10% of
>>   the time do NOT occur and run the GeSys application.  It
>>   has never succeeded in running the epics applications.
>> - Our host platform is RedHat 8.0 Linux on an Intel Pentium.
>>
>> Does anyone have any ideas as to what we are doing wrong?
> 
> 
> 
>> Thank you for any assistance you can provide....
>>
>> - Paul
>>
>>
>>
>>
>> Paul Jines
>>
>> Center for Advanced Microstructures and Devices
>> Louisiana State University
>>
> 
>