[Bug 1691] sparc64 usiii MMU trap handler crash

[bugzilla-daemon at rtems.org]

https://www.rtems.org/bugzilla/show_bug.cgi?id=1691

Gedare <giddyup44 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|FIXED                       |WORKSFORME

--- Comment #5 from Gedare <giddyup44 at yahoo.com> 2010-08-27 11:04:05 CDT ---
(In reply to comment #4)
> (In reply to comment #4)
> > 
> > One solution I can think of at the moment is to try to copy more of the
> > firmware. I'm not sure exactly how much needs to be copied though, and it would
> > be best to determine this amount off-line so that the linker knows about the
> > region of code being used.  An experimentally derived value of doubling the
> > copied space (from 32K to 64K) works on the Simics simulator.  The attached
> > patch introduces this doubling multiplier in the trap table size to accomplish
> > the copying.
> 
> As commented in the patch this is a hack. What happens if the firmware is
> upgraded and you have a number of different versions operating in the field ?
> 
Given the heavy reliance of the sparc64 ports to their firmware, I would
actually be very hesitant to upgrading the firmware without fully re-testing
anyway.  However, this hack is certainly very reliant on the firmware code
layout at present.

> > Another possible solution would be to install a replacement trap handler,
> > perhaps with a jump to the original trap handler (which still exists) in the
> > firmware.
> 
> If I understand this correctly, you turn the relative address into an absolute
> address when the new trap table is installed and call the absolute address
> pointing to the firmware ?
> 
The usiii BSP copies the firmware's trap table, but some of the instructions
that get copied are relative address branches.  These instructions would have
to be identified, and then the best thing to do would be to branch to the
original trap handler of the firmware.

Here is a sketch of what should be done for the better fix:
 * have a stored original trap base address: tba_original
 * read the new trap base address: tba_new
 * install an unconditional branch from the appropriate trap table entry in the
new table to the old table

The last step has all of the complexity, and involves generating a branch
instruction on-the-fly by computing (tba_original - tba_new) - (pc - tba_new).

> >  This would have to be done for every trap handler that branches
> > outside of the trap table.  Since the previous fix works, I did not investigate
> > this approach.
> 
> Sound like a much better solution.
> 
> I do not consider this issue resolved or fixed with the hack installed. Please
> consider reopening.
I don't plan to implement the 'more work' method since the current solution
works for me.  But I agree the current fix is not particularly pleasant. I have
sketched a better solution, and if I find the motivation or time I will revisit
this issue later.

-- 
Configure bugmail: https://www.rtems.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.