[U-Boot-Users] Generic ARM Error with respect to usage of r8 in start.S's.
r-woodruff2 at ti.com
Tue Jun 24 00:06:19 CEST 2003
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the U-Boot