Daniel Schwierzeck daniel.schwierzeck@gmail.com writes:
2016-09-26 9:58 GMT+02:00 Matthew Fortune Matthew.Fortune@imgtec.com:
Daniel Schwierzeck daniel.schwierzeck@gmail.com writes:
When booting from ROM, early exceptions can't be handled properly. Instead of busy-looping give the developer the possibilty to examine the situation. Thus issue a SDBBP instruction to transfer control to hardware debugger if one is attached.
You could make the SDBBP into a UHI operation that can be read by a debugger as an unhandled exception rather than an unexpected breakpoint (assuming said debugger knows about UHI). The fragment I use in lightweight boot code is:
move k0, t9 # Preserve t9 move k1, a0 # Preserve a0 li $25, 15 # UHI exception operation li $4, 0 # Use hard register context sdbbp 1 # Invoke UHI operationYou lose k0/k1 in this which may be undesirable but it might be a reasonable trade off. This shouldn't go in the debug vector of course!
sounds interesting. I'll have a look into that. Can I test this with OpenOCD and GDB?
I'm sorry to say progress with getting UHI into OpenOCD is rather slow. The main effort for OpenOCD has been part of the MIPSfpga project which I am not directly involved with. To my knowledge they have the basic 'write' call implemented but are not handling all the operations and the implementation is out of tree. I'll try and check on this and let you know.
I had an idea of using a special UHI operation to indicate a boot failure with a simple enumerated 'reason' code so you could get a quick hint at what blew up in low level boot code without the source. I.e. any errors that can be detected without ending up raising an exception. I put two quickly thought up errors into the UHI spec as an example but I only have some simplistic boot code to play with. If you think U-boot could have a range of errors to report like this (and want to use it) then we can add to the list.
Matthew