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.