MVME2304 Exception 3

[Joel Sherrill]

Till Straumann wrote:

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

I forgot about "far call" type limits.  I had never run into
that before.

This does make perfect sense because RTEMS allocates from
high memory to low memory because it makes the heap segment
splitting cheaper computationally.  The heap block stays on
the free chain -- it just gets smaller.


If this does in fact turn our to be the problem, then
it may be as simple as you say.  With a functional sbrk()
in the motorola_shared BSP and making sure RTEMS_Malloc_Initialize()
is passed a smaller "length" and the rest of memory as
the "sbrk_amount".

Then you can malloc() memory until you run out of low RAM
and malloc() will automatically call sbrk() with the sbrk_amount.

See the way the malloc initialization and malloc() work together.

--joel


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


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985