Hello,
I'm just fixing a
bug which I see exists in all the ARM ports. I just wrote a bit of code
for my arm925 which caused an exception, given the way the code is written one
would expect that it would print an error frame then possibly reset....instead
it just locked up. Tracing the code I see that the exception code in
start.S for all ARM ports uses r8 as a frame pointer. This is NOT allowed
as r8 is reserved as the global data pointer....given the way the ARM code
currently operates I don't see why this has to be, but it might be handy if
someone was trying to use C before the memory controller was up (this is not the
case for the ARM code today).
Anyway, what you
will see is :
A-- Program does something bad
-- takes the exception
-- the exception trashes r8
-- the code attempts to print the error, unfortunately the print code tries to
use r8 to find some info...
-- The dereference of the bad global data pointer messes up proper operation,
resulting in another data abort
-- Goto A:
For myself, I'll may
just remove the setting of the frame pointer into r8, it really gains you
nothing in this code. If exceptions were to be handled perhaps it might be
useful, but it still shouldn't be necessary as you should be able to unwind the
stack with out doing this. I'll have to do a little thinking to see what is
correct.
I'd submit patches
but I don't have other ARMs to test on so I'll just fix my 925 tree.
Having boot code which can get into an infinite loop is not a good thing
and forces power cycles for recovery.
Re-looking I see the
cpu/920 recently removed its r8 call for abort recovery, it did not however
remove it for its irq sources. So it could have some problems when the irq
function derefereced the pointer.
Regards,
Richard
Woodruff.