[U-Boot-Users] Generic ARM Error with respect to usage of r8 in start.S's.

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[U-Boot-Users] Generic ARM Error with respect to usage of r8 in start.S's.

Woodruff, Richard
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20030623/7c82af6a/attachment.htm 

Reply | Threaded
Open this post in threaded view
|

[U-Boot-Users] Generic ARM Error with respect to usage of r8 in start.S's.

Wolfgang Denk
In message <FD2AC9A020DDD51194710008C7089B20053D4CA9 at dlee17.itg.ti.com> you wrote:
>
> 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

What is it you don't see? Why we reserve R8 for global data?

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

...but may change any day. As soon as there is a little time left for
"nice to have" things.


Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Program maintenance is an entropy-increasing process,  and  even  its
most skilfull execution only delays the subsidence of the system into
unfixable obsolescence.       - Fred Brooks, "The Mythical Man Month"